[Dextrose] Sugar updater.

[David Farning]

On Mon, Nov 15, 2010 at 4:30 PM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Mon, Nov 15, 2010 at 01:26:58PM -0600, David Farning wrote:
>> 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
>
> What dates you have in mind, min (would be nice to have in..) and max
> (will be bad to not have until..)?
>
> What minimal fedora version will be for deployments that will start
> using the updater?

I am not sure about either of these issues.  I would suggest
implementing something that seems reasonable to you.  We can then make
adaptations based on deployment feedback.

david

> Just some thoughts I have in mind:
>
> * +1024 for having diversity of sugar doers' efforts (from sugar window
>  manager to flash activities) but -1 for having diversity for core
>  technologies that support doers' diversity (here, update related core
>  technologies, not hight level tools). So, would be good to use the same
>  low level mechanisms for as many sugar envs as possible.
>
> * So, using PackageKit should be useful. It will work not only on
>  fedora/dextrose but also on all major distros.
>
> * [1] will also use PackageKit, thus keeping things in one code base
>  will be useful (no need to scatter development/supporting efforts).
>
> --
> Aleksey