[olpc-software] Package manager stuff

[Mike Hearn]

On Wed, 2006-03-15 at 23:41 +0000, Daniel P. Berrange wrote:
> 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.

It's not really fooling programs, it's more that you need some way to
find files that match certain criteria. If you don't use unions (or fake
it with symlinks) then you need some other type of database. If you do,
then the filing system takes care of things automatically for you.

> For example, consider an app whose binary is named 'wizz'. 

It does solve the problem though, that's the point :) Today with package
management this is a real issue that cannot be solved by the user, but
in the proposal if a conflict happens this is what happens:

* typing "wizz" from the command line matches /usr/bin/wizz as it's
  in the path, and you get the systems copy. If that's not what you
  meant you can run /applications/wizz-1.0/bin/wizz and it will
  work correctly.

* man wizz shows system copy. 
  man -l /applications/wizz-1.0/man/man1/wizz.1 does what you mean

So you can still disambiguate at the command line level quite easily.

This is what happens for the GUI users:

* {GUID}.desktop is merged into /usr/share/applications, GNOME sees
  it, and the user gets "Applications -> Widgets -> Wizz" in the menu.

     * If the two Wizzes actually are different, then they appear in
       different places in the menu and there's no ambiguity
     * If the two Wizzes are the same, then you see two copies in 
       the menus. This is a GNOME/XDG bug that needs to be fixed
       anyway - when two menu entries would have identical display
       names, it needs to add data to it until they are no longer
       identical. For instance one might show as "Wizz 1.0" and another
       as "Wizz 2.0 beta"

* Running it from the menus/opening a file associated with it causes
  the desktop to run the absolute path /applications/wizz-1.0/bin/wizz
  so it works correctly.

> If core system services like dbus, bonobo, fontconfig are unable to find 
> config files for software installed into these locations this must be fixed.

That would be nice for sure. And I've filed many bugs in Red Hats and
other distros bugzillas over the years to get /usr/local fixed, but it
never happens (very low priority basically). And the list of things that
need to be changed grows all the time.

It also doesn't solve the problem of conflicts at all, because two 3rd
party programs with the same name can still conflict.

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

Exactly! And that's why it's important. In this scheme applications just
provide a UNIXish install tree that can be put anywhere. Then the system
transparently takes care of hooking it into the menus, dbus, file
associations, icon themes and so on.

Right now what happens if you install a program to some custom prefix?
Nothing happens - no desktop integration at all. And you can't update
environment variables after the desktop has started so even if you edit
all the config files and env vars you must log in again to make it work.

The union scheme fixes all this, because GNOME will be
watching /usr/share/applications and the moment a new application is
found by the system a la MacOS X it's integrated with the system.
Otherwise you have to set XDG_DATA_DIRS to a big long path.

thanks -mike