[Dextrose] Sugar updater.

[Aleksey Lim]

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?

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