[olpc-software] Package manager stuff

[Mike Hearn]

On Tue, 2006-03-14 at 13:13 -0500, Alan Cox wrote:
> 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.

On the basis that I see people having problems using them every day.
Typical problems include:

* Software I want is missing
* Software I want is out of date
* I followed instructions on the web page which usually means I tried
  to compile something and failed
* I do not know these tools exist (even if they're in the menus, I do
  not think to look there as Windows/Mac don't work that way)
* I cannot find what I want (see synaptic)
* I found what I want but due to a mistake by the packager it does not
  install
* I found what I want, installed it, and now my system is broke
  (for instance that was happening for the Banshee nrpms packages
  a few months ago)

Like I said, go look at web forums (where the *real* newbies post) to
see lots of threads with people having these problems. So I claim these
tools are not robust enough. At least not for a world without sysadmins.

> We don't have union mount support currently. 

In kernel, no. But it does exist. There is even a FUSE implementation.

> And union mount with notifiers really really hard to do right and race free.

The union mount itself would not be watched. The actual, physical
directories would be watched.

> So if you think there is corruption how do you run a verify ? 

Hmm, my rpmdb has become corrupted far more times than the actual files
have been. You could store a set of /system file hashes separately, but
I think it'd be bad to store them on the laptops storage itself because
that is so limited. Every byte counts, right?

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

That's an artifact of current Linux packaging conventions. Look at how
it's handled on Windows or the Mac, and you'll see that these operating
systems have no issues with users running two versions of things at
once.

I think apps can be made to find their own files OK even in the case of
union mount conflicts if they always resolve their paths relative to
dirname(/proc/self/exe). If there was a /proc/self/exedir then most open
source software could be compiled as "./configure
--prefix=/proc/self/exedir", and at this point the union mount is useful
mostly because GNOME/DBUS/etc expect to find things in magic locations
in /usr. But it wouldn't be so the app can find its own files.

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

Could be! I don't know exactly what is needed of these laptops. But I
don't think a Nokia style internet appliance is really the same thing as
a fully blown computer. You don't expect to be able to easily swap
software with other N770 users, instead, you expect to install it from
the web. To download it then send it to somebody else you'd have to keep
the package around, which wastes storage space. There is no attempt to
deal with two programs that happen to share the same name. 

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

TBH if desktop-Linux-the-OS was 'done' then I'd have no real concerns
about giving it to my friends, but I already tried that and got a
constant stream of "help it doesn't work" type requests, often related
to handling software in some way.

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

Configuration files aren't changed, unless the update needs them to
change, in which case a textual patch can be shipped and if it doesn't
apply then do what RPM does now - just save the new copy somewhere else.

But kids shouldn't be modifying core configuration files. Nor should
their teachers.

Library updates don't break apps, because the distro is carefully
controlled to ensure that it doesn't happen. ABI checker tools exist and
can be improved, updates can be QAd as usual, and only libraries with a
firm upstream commitment to compatibility would be a part of the
platform.

Microsoft and Apple have a lot of experience with this stuff - managing
a stable platform *can* be done, the fact that current Linux vendors use
depsolvers as a way to avoid it doesn't imply the same should be done
here.

thanks -mike