OLPC-Update + RPMs WAS:Re: OLPC XO Opera browser as Sugar activity

[david at lang.hm]

On Fri, 27 Jun 2008, Erik Garrison wrote:

> On Fri, Jun 27, 2008 at 12:17:57PM -0700, david at lang.hm wrote:
>> On Fri, 27 Jun 2008, Erik Garrison wrote:
>>
>>> We should move away from using olpc-update to upgrade systems.  We
>>> should not implement this or any hack to preserve manually installed
>>> rpms through olpc-updates.
>>>
>>> Existing package managers (e.g. apt, rpm) do exactly what we want and
>>> more.  Furthermore they are extensively tested and well documented.  Why
>>> have we locally manufactured and promoted the square wheels of
>>> olpc-update and copy-nand?
>>
>> every existing package management system makes assumptions about how
>> large an upgrade you are making. even apt (historicly one of the best
>> long-term systems) runs into significant problems if the upgrade that you
>> are making is too large, frequently without being able to identify the
>> problem ahead of time.
>>
>> with yum, can you (in one step) do an upgrade from Fedora 7 to Fedora 9?
>> I don't think it can.
>>
>
> It can't be done in one step, but people use yum for distribution
> upgrades already:
> http://www.howtoforge.com/upgrading-fedora7-desktop-to-fedora8
>
> Recently I have been completing my Ubuntu distribution-level upgrades in
> one step.  So we should know that it is possible that such upgrades can
> happen within the scope of a package manager.

ubuntu uses apt, doing an upgrade from one ubuntu/debian release to the 
next works well, but if you tried to skip a couple releases and then do 
the upgrade you may run into 'interesting' problems (not becouse it can't 
work, but becouse the debian/ubuntu developers don't take the time and 
effort to define all the gotchas for the multiple step upgrades to tell 
apt how to do them properly)

OLPC has a much smaller developer base, and are already questioning how 
many releases they can support. the problem of how many upgrade scenerios 
to support, and what to do for the ones they don't support is an area they 
really don't have the manpower to tackle

>> the snapshot based approach has headaches, but the one huge advantage
>> that it does have is the ability to do the upgrade no matter what the
>> condition of the old system image is (including the possibility that the
>> system image is corrupt)
>>
>
> IMO, the snapshot approach has headaches for everything *but*
> distribution upgrades.  How, for instance, do we issue security updates?
> How do we push small bugfixes?

that's easy, you treat them like distrubution upgrades. the only place 
this runs into problems is where people have added their own packages, and 
it's impossible to anticipate what will break those without extensive 
testing of all the combinations, so changing the upgrade mechanism isn't 
going to help.

> This is problematic for developers,
> users, and particularly the support staff which have to sheperd users
> through monolithic upgrade processes.

it's a lot easier to shepherd people through the monolithic upgrade 
process that always works then it is to have to deal with multiple 
different upgrade processes, and teach people which one to use when.

> Despite any apparent vitriol to the contrary, I am not suggesting we get
> rid of snapshot based upgrades.  They can obviously coexist with a
> well-maintained package management system vector for upgrades.  It will
> always remain a useful sledgehammer.  However, if we wish to preserve
> custom packages across such upgrades I suggest we can use a system such
> as yum rather than hacking olpc-update to play nice with the packages.
> Evidence strongly suggests that this is possible.
>
> What functionality do we certainly lose by using a package management
> system as our default software distribution system?

it's not that we loose functionality by using a package-based approach, 
it's that we increase complexity and eat up scarce development resources. 
You see the fact that this may work better with custom packages as a big 
advantage, I think that people who do custom packages can deal with the 
complexities themselves, and that they are very much the exception rather 
then the rule. by far the most common situation is, and is going to 
continue to be, the case where the laptops are running a standard image 
with no additional packages (note that this 'standard image' may be 
defined by the country, not OLPC, and therefor may contain some packages 
not in the OLPC image). it's only a small subset of the G1G1 and 
development machines that will have custom packages on them.

for the record, there are a couple packages that I install on my XOs, I 
just store the .rpm files on a SD card and have a script in my home 
directory that installs them. after each upgrade I open a terminal and run 
that script

David Lang