[Dextrose] Sugar updater.

[Steven Parrish]

On Mon, Nov 15, 2010 at 7:18 PM, David Farning <dfarning at gmail.com> wrote:
> 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
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose
>

This system will just be updating the Sugar base system not the
activities.  YUM can already do this just need to disable the stock
Fedora repos and enable a Sugar update repo.  This can be done in a
bash script and run via a cron job.

Steven