[olpc-software] Package manager stuff

[Alan Cox]

On Tue, Mar 14, 2006 at 06:02:36PM +0000, Mike Hearn wrote:
> * Kids want to be able to share software with each other easily
> * It must be super-robust. RPM/apt technologies are just not robust
>   enough

On what basis ? Looking at the vast number of systems using these technologies
they appear robust and the ipkg variant has solved the size problem too.

> a watch on it. As subdirectories come and go, they are union mounted
> over /usr which becomes a composite of the system and each individual
> piece of software on the system. /applications is not the only place
> that can be thus monitored - removable media and net mounts can be too.

We don't have union mount support currently. And union mount with notifiers
is really really hard to do right and race free.

> There is no package manager database, because the filing system
> namespaces can replace it entirely.

So if you think there is corruption how do you run a verify ? How do you debug
an oddly behaving box when you can't even work out what software is actually
running and if its complete, correct and the right one.

> * You can have multiple versions of programs installed at once. Useful
>   when you aren't sure if the new version will meet your needs or not
>   (or for people testing alphas/betas).

You've never done package management have you 8). This doesn't work because
of the inter package dependancies. If mozilla 1.4 wins the union mount and
firefox using different libraries comes second one breaks. And mucking with
LD_LIBRARY_PATH doesn't help much either because programs run each other.

> in building packages. That way the OLPC project can focus engineering
> time on actually fixing the OS rather than wrapping programs into OLPC
> specific RPMs/DEBs.

I don't think there is much OS work to do. If someone came to me with the
basis of OLPC as a business proposal then my immediate reaction would be
to say "screw all this funky experimental stuff", we know ipkg works, we
know X works, we know jffs2 works, we know busybox works. We have recipes
that have churned out millions of reliable appliances and small devices that
are there to use. OLPC/iPaq Linux/Nokia770 are all such close cousins that
the rocket science has been done at the low level and I think re-doing that
rocket science is just a good way to make the project late, buggy and fail.

There is a lot of cool stuff needed - but its almost entirely on the top of
the stack. Linux/X/libc/busybox/blah is simply the mechanics and not the place
to try new and clever tricks when they are not needed. Lets leave the magic to
the folks writing the educational software and UI top level.

> removable media easily. They'd be downloaded and applied automatically
> by default. This scheme improves bandwidth efficiency over the current

And configuration changes are preserved how. Who deals wiht incompatibilities
with the applications introduced by updates changing version of a library or
the like ?

And yes that happens, sometimes to make it really painful the API change is
a security fix and the API change is needed to solve the problem.

> system used in Fedora.

Fedora tries to solve a different scaling problem - resource usage on the
server end and resource requirements on the server end. When you've got
3000+ sessions per server box you can't afford the cost of fancy rsync and
related tricks so you don't pull them.

Alan