[olpc-software] Package manager stuff

[David Zeuthen]

Hi Mike,

On Tue, 2006-03-14 at 18:02 +0000, Mike Hearn wrote:
> What I wanted to try is simple enough. The base operating system/desktop
> platform is installed as per normal

An interesting question is indeed what "base operating system/desktop
platform" entails; not sure everyone is on the same page here... This is
the bit we're currently working on and right now the plan is to include 

 1. Linux kernel

 2. Core OS bits (D-BUS, HAL, NetworkManager etc.)

 3. X.org X11 server and X11 Window Manager (right now we use Matchbox)

 4. Desktop toolkit and libraries (GTK+, gstreamer, gconf,
                                   gnome-vfs and so forth) 

 5. Some kind of panel for launching applications - needs user
    experience analysis and design
    - should probably support fd.o notification area since we most
      likely want gnome-power-manager, NetworkManager GNOME icon etc.

 6. Some yet to be determined way of managing files and documents;
    needs user experience analysis and design
    - can potentially integrated with a panel

 7. Web Browser; maybe not Firefox but probably Gecko based

 8. Potentially other core apps; e.g. perhaps a word processor,
    media player etc.

 9. Some way of managing external applications

and all this software itself is managed through RPM and built into
images where we strips the yum, rpm tools and their associated databases
before they hit the OLPC laptops.

All RPM's stem either directly from whatever Fedora (or RHEL) we're
going to end up basing OLPC upon. We realize we need to modify some
RPM's like e.g. the kernel but we believe this can be kept to a minimum.

Our image build tools also strip out unwanted files and locales; this is
a temporary workaround; we plan to fix the RPM's in Fedora to make said
files and locales optionally installable etc. We don't expect big
arguments with existing Fedora package maintainers about these changes
(and right now we're just waiting for FC5 to ship so we can start
breaking Fedora Core Rawhide)

All these bits constitute the "core (desktop) OS" bits and they also
constitute a platform and in that respect an ABI. We also plan to extend
some of the ABI guarantees that e.g. GTK+ gives you though we certainly
won't give guarantees for certain ABI's like e.g. some kernel interfaces
such as /proc or /sys.

I'm reiterating all this to give some kind of insight to what kind of
"external applications" we can expect.

> , then /usr, /etc and /var are moved
> to /system/usr, /system/etc and /system/var. A new /applications
> directory is created and is monitored by a simple program that registers
> 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.

I like this idea a lot. Notably, for system integrity reason, we'd keep
the core OS bits on a separate read-only partition that is only mounted
read-write when applying core OS updates (note: yes, jffs2 needs a fix
fixes so we can have multiple partitions). Notably the partition for
"/applications" would be mounted read-write; it will probably also be a
different partition than "/home".

> Unsurprisingly, my personal feeling on this is  that having a repository
> for OLPC laptops is silly and that it'd be better to share binary
> autopackages with other distros. That way (at least in theory) more
> software will be available sooner because any Linux user can take part
> 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.

Yes. While I personally like Fedora Extras (it got a lot of really great
and useful software), I'm personally not sure either it's the ideal
distribution method of software for the masses.

Btw, I was wondering whether we really need union mounts to make your
proposal work? Won't playing tricks with PATH and LD_LIBRARY_PATH work
instead? If so, what are the constraints of this? Things like IPC and
other stuff comes to mind.

(yes, I really wish myself that we had union mounts, don't Darwin or Mac
OS X support this btw?)

Oh - our image build scripts will make this somewhat easy for you to
experiment with [1] as the whole OS is prepared there. Personally I
think it would be really awesome if you/we could come up with a solution
(based on autopackage? modified?) that fits both the requirements we
come up with (cf. you mail about use cases and design which is good) and
is feasible to implement kernel, user and desktop-space wise.

Cheers,
David

[1] : I'm not sure if our Mercurial repository for these tools are
publically available yet, but if it's not it will be as soon when FC5 is
out - the people controlling servers in our DMZ have been / are busy
with Fedora and RHEL update releases...