[Dextrose] Sugar updater.

[David Farning]

On Mon, Nov 15, 2010 at 6:41 AM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Sun, Nov 14, 2010 at 01:39:00PM -0600, David Farning wrote:
>> Aleksey,
>>
>> As part of you long term update project would you please start working
>> on a yum based update system for deployments.  Standard system
>> updating is a solved problem on Linux.
>
> Well, it is not only for updating issue (this system might be useful for
> centralized deployments only as a central place for keeping information
> about all sugar projects and as a build farm, in both cases it will be useless
> for dextrose since it has chosen another way) but more about doers'
> environment [1] which also based on regular (ie ditro) instruments
> like yum/apt :)

I am sorry but I didn't understand much of this.  The fault is
probably my lack of understanding of the technical issues.  I will
spend a few hours going over the zero install and your other work.

>> While there might be value to
>> a fully functioning atomic updater.  A working yum based updater is
>> more valuable to deployments.
>
>> Based on conversations with deployment service and support personal I
>> would suggest.
>> 1. No user interaction required -- A cron based base yum updater which
>> runs every two weeks should be fine.
>> 2. Final mile rpm distribution can depend on the Squid caching at the
>> school server level.
>> 3. We will need to be careful at the deployment level.  Every school
>> server hitting the deployment server at the same time could be
>> problematic due to bandwidth constraints.
>> 4.  One of the important lessons we can learn from RHEL is providing
>> stock dextrose in a known location with good release note.  Then
>> deployments can either use the stock dextrose repos or cherry pick
>> patches and create their own update repos.  It is pretty common to
>> deploy updates on test systems before updating everything system wide.
>> 5. The build process already creates the necessary RPMS at
>> http://download.sugarlabs.org/dextrose/testing/dxo2/rpms/i386/os/ . As
>> several people have pointed out, we are going to have to work together
>> to settle on a sensible release naming system.
>
> If I got it right, it is all about fetching updates on dextrose user
> side? i.e., coding non-visual and visual components for sugar shell?

I think there will be two sides:
1. Client side code.
-- update code
When thinking about this it seems that we can shoot for 'no less
functionality than fs-update.  If there are memory limitations, we
don't need to enable multiple repos by default.  IE if you update via
fs-update you get a predefined set of packages.  so we can limit the
number of packages available in the dextrose update repo.

If the update fails we can fall back to reinstalling via USB img.

2. Build system.

On the build system it would be great to have a logical progression of
repos which match os imgs.

david


> [1] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Doer.27s_environment
>
> --
> Aleksey
>