[Dextrose] Sugar updater.

[David Farning]

On Mon, Nov 15, 2010 at 12:40 PM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Mon, Nov 15, 2010 at 12:12:06PM -0600, David Farning wrote:
>> 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.
>
> np, I just meant that most useful features are intended directly to the doer
> rather than deployment infra. Moreover, I think that what you mean for
> "yup updater" can be implemented as a subset of an updater for [1].
>
>> >> 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.
>
> btw there I can find fs-update source (I can't find a package that
> contain this command).
>
> If I got it right, the plan is not inventing new entities (in meaning of
> Ockham's razor) in case of packages updates (+1 for that), and just having
> one/several dextrose/dextrose-derivates yum repos and have make update
> process:
>
> * implicit (though, having optional UI/cli tools would be good, I think)
> * customized in case of attaching new repos (eg local repos for
>  particular deployment)
>
> Thus, nothing but just package updater which is convenient for dextrose
> deployments needs?

Yes.

>> 2. Build system.
>>
>> On the build system it would be great to have a logical progression of
>> repos which match os imgs.
>
> As I see current picture, there is no need in coding on build system
> side, we just need to provide proper info about what repo belongs to
> what deployed image?

Yes

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