[Dextrose] Sugar updater.

[Aleksey Lim]

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?

> 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?

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

-- 
Aleksey