[olpc-software] Package manager stuff

[Daniel P. Berrange]

On Wed, Mar 15, 2006 at 08:07:36PM +0000, Mike Hearn wrote:
> On Wed, 2006-03-15 at 14:22 -0500, David Zeuthen wrote:
> > 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.
> 
> Union mounts are not totally essential. I proposed them because a _lot_
> of software assumes everything is installed under /usr, /etc and so on.
> 
> You don't realise how deep this assumption goes until you try and let
> people install software elsewhere - as both autopackage and CodeWeavers
> products let users do this to some extent I've experienced this pain
> directly.
> 
> For instance, consider the following things that have to be adjusted to
> enable a new prefix to work correctly:
> 
> * Shell PATHs. For every shell, mind, not just bash.
> * DBUS config file needs to merge paths
> * Fontconfig config file needs to merge paths
> * $XDG_DATA_DIRS
> * Menu XML definitions sometimes need to merge in extra .desktop
>   directories
> * Bonobo activation paths
> * Linker paths
> * man/info paths
> * screensaver paths
> 
> The list never seems to end. Certainly adjusting all these paths at
> runtime would require serious patching action.

First of all, I agree that these are all real problems when trying to 
install stuff into a hierarchy other than /usr. I think, however, that
trying to implement a solution to fool apps from /opt into thinking it
is really in /usr is the wrong way to deal with it, not only in context
of OLPC, but for Linux or any UNIX OS really.

One of the design requirements for the OLPC OS platform is to make the
system bullet-proof in terms of administration. Users should not be able
to accidentally break the OS when downloading the latest game. Simiarly
when upgrading the OS platform, all add-on apps must keep working as before.
Making both the core OS and user apps share the /usr namespace (either 
virtually via a magic unionfs, or physically by directly installing to /usr)
is going to open the door to an unneccessary world of pain. For example,
consider an app whose binary is named 'wizz'. Now if there is already
a binary in the OS platform called 'wizz' then either the OS binary will 
stop working or the user's app will fail to work - neither scenario is 
acceptable. Adding priorities "OS overrides user apps" or vica-verca does
not solve the problem.

Build tools such as IMake, AutoConf & friends have long supported a user
customizable install prefix. This lets an admin install un-managed pkgs
into, say /usr/local, or a user on a shared server install software into
their $HOME, or a software developer to install into a private directory
for testing during development. 

If core system services like dbus, bonobo, fontconfig are unable to find 
config files for software installed into these locations this must be fixed.
The linker allows LD_LIBRARY_PATH, the shell allows PATH, man allows MANPATH, 
etc so this is not a technically hard problem to solve.
Now I don't doubt that there are many existing software packages that
are hardcoded to assume they install into /usr, even though their AutoConf
scripts allow --prefix during compilation. These can & should be fixed,
because this already causes pain & suffereing for existing non-OLPC users
who don't have root on machines. 

These past 3 paragraphs have all been down in the implementation weeds
though - we need to step back a bit. For OLPC we are not trying to put
together 'yet another Linux distribution'. We are trying to build a 
platform for educational / learning applications, that just happens to
be based on Linux. So we need to ask what we mean by the application
development platform. 

The discussion thus far has tacitly assumed that the platform encompasses
the entire Linux OS. This is *not*, however, what we have been aiming for.
Rather we consider the platform to be a collection of libary APIs and 
services. Consider Mac OS-X for a minute - this is based on a comprehensive
BSD operating system - the BSD OS is *not*, however, the platform to
which application developers build. Apple publish & document some set of
APIS & services for application developers to use. In particular the 
directory structure /usr, /bin, etc is *not* part of the platform for
app developers.

As a stretch goal I'd like the OLPC application development platform to
to be defined in a similar way to Mac OS-X platform. Just a set of libraries,
and services - the UNIX filesystem & underlying OS bits are of no business
to the applications. So really this whole dixscussion about unionfs and
installing into /usr is completely irrelevant. User applications have no 
business knowing about, or needing to use /usr.

Now, this is not to say we're going to lock the user out of the OS - just
as in Mac-OS X  the user can get under the hood and poke the UNIX OS, but
this is really just for fun / learningi - its completely uneccessary for
Joe average user unless they want to know about it.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|