OLPC-Update + RPMs
mikus at bga.com
Sat Jun 28 01:34:29 EDT 2008
> We should move away from using olpc-update to upgrade systems.
Am having a hard time understanding the problem Erik is addressing.
I do *not* consider the effort that has gone into olpc-update to be
I think decent 'one-click-installs' are wonderful when they work,
but leave the user stranded when they don't. [It's hard to
anticipate *everything* that might go wrong, and provide "automatic"
recovery.] For an OLPC upgrade, I think there will always need to
be a person to make sure everything worked (a person who can follow
Let's look at how many users need that specific upgrade.
[All these methods are suggestions - any of them might be used in
any particular situation.]:
* If it's one user, then I believe the "mechanism" best suited to
do the upgrade is determined by where the fix is available:
- If it is a "whole-OLPC" upgrade, skip down to '100 users'.
- If the fix is in a koji-type repository, use a package
manager (e.g., yum) to install that fix.
- If the fix is a file, fetch (e.g., wget) that file, then use
the appropriate tool to install it (e.g., 'rpm' for system
stuff, or 'sugar-install-bundle' for application stuff.
* If it's more than a dozen users (e.g., one school), then I
believe a "mechanism" like 'customization' key should be used.
It would be an administrator/technician who prepares the
portable device with the fix.
If it does not exist already, OLPC development needs to create
the script which performs the actual upgrade from the files on
the portable device. [Provision needs to be made for upgrading
both system stuff and application stuff.]
* If it's more than 100 users (e.g., one country), a "whole-OLPC"
reload might be easiest to manage (using e.g., 'olpc-update'
to affect system stuff only, or a 'customization' key to affect
application stuff only; else the whole OLPC could be wiped with
Secure Upgrade, or even with the 'customization' method. The
"country release team" would probably be the ones to prepare
the media from which such a "whole-OLPC" upgrade is distributed.
With all of these methods, a form of 'dependency hell' may arise.
If only some modules are replaced, they might not work with whatever
that user has done to the rest of his system. If all the system
modules are replaced, whatever system customizations that user had
already applied may have to be re-applied; also, some applications
the user had already installed may not work with the new system.
Erik makes the suggestion that a package manager ought to be used to
implement software update procedures (e.g., as in 'dist-upgrade').
The difficulty that I see is that the __packages__ made available to
that package manager will have to include 'rules' to address the
'dependency hell'. Currently, modules at a certain level are
gathered together into a build; if that build is to be "official",
the working together of its modules is tested extensively. Package
managers handle individual packages - each would have to indicate
which other modules/versions it would conflict with. Lots of work.
> What functionality do we certainly lose by using a package management
> system as our default software distribution system?
The "country release team" loses some degree of control. With an
"official" build installed monolithically, there is some degree of
assurance (to the end OLPC user, and to whoever paid for that OLPC)
that it will "just work". When package management as the
distribution method, who knows whether any OLPC user might
accidentally end up with an oddball mix of installed modules.
More information about the Devel