Re: Relocatability of packages

[Tim Moore <tmoore tembel org>]

On Thu, 24 Sep 1998, David Jeske wrote:
> On Thu, Sep 24, 1998 at 06:13:19PM -0400, Tim Moore wrote:
> > On Thu, 24 Sep 1998, David Jeske wrote:
> > [snip]
> > > When I think of relocatility of packages I think of getting rid of this:
> > > 
> > > /usr/local/bin/balsa
> > > /usr/local/bin/wmprefs
> > > /usr/local/balsa/balsa.ico
> > > /usr/local/wmprefs.app/<stuff>
> > > 
> > > and moving to this:
> > > 
> > > <anypath>/balsa.app/balsa
> > >                    /balsa.ico
> > > <anypath>/wmprefs.app/wmprefs
> > >                      /wmprefs.ico
> > > 
> > 
> > So does that mean you have to put every *.app directory (which may be
> > scattered around the system) in your path? Wouldn't building menus for the
> > GNOMEprint and whatever be a big headache? And what about the separation
> > of system-independent vs. system-dependent data?
> 
> In Nextstep, there was a 'gui app path' which the system libs would
> look through to find ".app" wrappers. If you put the app in one of
> those directories, then the system would know about it, and
> automatically register it's filetypes, etc. If you didn't put it in
> one of those paths, you could still "launch" it by double clicking on
> it in the filemanager.

OK, that makes sense. But I don't like this hard separation between gui
and non-gui. What if I want my package to have GUI *and* CLUI tools? Or if
I want my one program to be usable in both modes? I don't think the GNOME
project intends to deprecate the command-line as much as NS did, and I
think that there's more of a portability concern, too. I have strong
reservations about changing around commonly accepted filesystem layout *by
default* (though we should make it as easy as possible to do whatever you
want to on your own system).

> Building menus in this scenerio is actually much easier, both because
> you know exactly what you have to do to find all the apps which are
> installed (i.e. go torough the app paths looking for app wrappers) but
> also because apps passively export information such as their icon,
> etc... so any program which wants to display the icon for "foo.app"
> can just go in and display "foo.app/foo.ico", and it just
> works. Instead of the current Gnome/Linux fiasco where you have to
> configure the window manager for the applications you have installed.

I don't know what you're talking about when you say you have to configure
the WM for all the applications you have installed. *I* don't have to. Are
you talking about the icon for minimized windows (which the app is
supposed to provide via WM hints) or for the panel (which the apps install
themselves in <prefix>share/apps)? If you're talking about some other
launcher that your window manager has, then GNOME has already solved that
problem.

> System dependent data should be stored in libprefs....

I actually meant architecture dependent data. The nice thing about
separating out bin and lib is that you can have one fileserver per
architecture, and put all of the arch independent stuff (icons and
whatever) onto a central server. (Unfortunately RPM doesn't seem to
support this well anyway...I don't know about dpkg).

What is libprefs? I assume its some library for storing preferences (duh)
but is this something that exists for Unix? I'm aware of such a thing for
BeOS, but I haven't seen it on Linux. Or are you just speaking
hypothetically?

And where would the libprefs data be stored?

> Furthermore, the unix /usr/local/bin path thing is only convinent if
> your environment is sufficiently simple. Back at a former company I
> went through the trouble to make a system which would custom build
> paths based on a set of 'packages' which should be in the
> environment. Essentially adding all the encapsulated wrappers to your
> path for that given environment. It was the easiest way to (a) keep
> environments repeatable as we moved forward, and (b) allow multiple
> versions of the same apps to be installed at the same time. Both of
> which are _necessary_ for any orginization which is more than just a
> few people.

OK, I can't say that I've had to deal with an organization which is more
than a few people. :-) I have a hard time swallowing that you need to keep
lots of versions of the same apps around, but I'll take it on faith that
you know what you're talking about. But it sounds like an administration
and support nightmare to me. Why did you need to do that?

> > It was kind of cool the way NEXTSTEP encapsulated a package in a
> > directory, but I don't think it always scales well, or that it works in
> > all situations. I think that modern package managers do a good job at
> > solving the same problem without imposing their own structure on the
> > filesystem.
> 
> 
> In my opinion and experience, it works alot better and scales alot
> better than the current Gnome system of throwing everything together
> in a single directory. However, I'm willing to put it to the test.

Well, frankly I don't like the throw-it-together-in-one-directory method
for reasons relating to installation management, but more for usage. I
think that packaging systems do fine for installation, and deal with the
problems of throwing everything together pretty well. I honestly like RPM
a lot better then Mac OS or BeOS where you could theoretically put
everything in one directory but there were always exceptions like shared
libraries which needed to go where the loader could find them, and
manpages which have to go where man can find them (or the gnome-help
browser) or command-line programs which have to go somewhere in my PATH...

> Why don't you enumerate the things which are important to you in app
> installation and we'll put our lists together and see what systems can
> meet the goals?

1 users shouldn't have to do anything special (modifying PATH or whatever)
  to use new packages
2 packages don't have to go in any particular place (NOTE: This may
  conflict with the previous requirement, butdoesn't have to if the
  sysadmin uses a sensible policy. Of course, the default should be
  sensible, too)
3 handles dependencies gracefully
4 handles removals/upgrades gracefully
5 separates static data and dynamic data so that the static data can be
  mounted from a fileserver
6 handles upgrades of dynamic data gracefully so that changes in the the
  package don't clobber changes made locally (and preferably allows
  merging the upgrades together perhaps by diff3-ing the original version,
  the installed version, and the upgraded version)
7 separates platform-dependent and platform-independent data so that they
  can be mounted from different fileservers
8 handles all packages in a uniform way, whether they are all-GUI,
  all-CLUI, all-daemon, or some combination

If the sysadmin installs them in a reasonable location, RPM and dpkg both
handle 1. It's unclear whether the .app system would -- this will require
more discussion.

The .app system handles 2. So does RPM, assuming that the package was
built to be relocatable. Often they are not, but the .app system assumes
that anyway. I don't know if dpkg allows that...it appears not. Note that
this would allow normal users to install apps if satisfied.

dpkg does 3. RPM does too, but it's somewhat less graceful. .app would
seem not to, at least as it's currently proposed.

dpkg and RPM both handle 4 well. .app would handle it *pretty* well (you
would just remove the old directory and optionally replace it with the new
one) but misses some subtleties.

dpkg and RPM both handle 5 well. I don't know about .app since that hasn't
really been specified completely.

dpkg and RPM both handle 6 well, though neither of them do the diff3-ing,
AFAIK. .app doesn't handle it at all, at least so far.

7 depends pretty much on the packager with dpkg and RPM. .app explicitly
*encapsulates* the two types of data.

RPM and dpkg handle all packages the same. As it stands, .app only works
for GUI apps (and only for packages which only have one executable).

> Here is my list:
> 
> - install multiple versions of the same apps

As I said, this confuses me a bit. It seems like it would be very
difficult to keep the versions from conflicting. How, for example, do you
handle configuration files?

> - allow user's to install applications (no superuser required)

We agree on this.

> - trackability (i.e. the ability to delete everything related to an
>   app/package easily)
> - repeatability (i.e. the ability to recreate a requred environment/
>   set of apps on another machine quickly and easily)

Both easy with package managers.

> - separation of 'immutable' (i.e. part of the distribution) app
>   data from 'mutable' data. 

Agree on this, too. But you haven't really fully explained how .app
encapsulation resolves this.

> This is a set of goals mostly for 'end user/GUI' apps, and while it
> mostly applies to server apps, I don't think we should bother with
> that now.

Well, it can be tough to draw a distinction sometimes. GNU Midnight
Commander is ostensibly a "end user" app, but comes with a server. On the
flip side, what if I want to distribute my server with my nifty graphical
configurator?

> The current Gnome system can not handle the first two. Because of
> that, it can't handle "repeatability" either (because I can't recreate
> an environment which needs Netscape 3 somewhere that already has
> Netscape 4 installed).

But Netscape has other problems with conflicts that are internal. I can't
switch back and forth between two versions because they have incompatible
preference files. And even different users on the same system will run
into problems with any program that uses system-wide configuration files.

Still, I can see your point. Perhaps executables should mirror shared
libraries somewhat. The Netscape 3 package could install:
/usr/bin/netscape.3.0
And the Netscape 4 package could install:
/usr/bin/netscape.4.0
You could specify to the package manager which version was the default,
and it would make a symlink:
/usr/bin/netscape -> netscape.4.0
and associate that with the 4.0 package.

But there are still problems. What about documentation? This will require
some thought.

> I personally don't think it separates immutable
> data enough. The "trackability" can be had right now only _IF_ you use
> a package manager. So all the people currently doing "make install" on
> source for Gnome apps don't get trackability.

I think it's reasonable to assume that if you want trackability, you will
probably use a package manager. Even building out of CVS, it's possilbe to
compile to an RPM and install that (that's what I do).

Tim