Re: Relocatability of packages

[David Jeske <jeske home chat net>]

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.

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.

In a command line shell in Nextstep, if you wanted to launch a program
you had to typed it's full path. Which means that to launch edit, you
would have to type "/NextApps/Edit.app/Edit". Except that (1) nobody
ever did this, and (2) if I were doing it, I would change the command
line tools to use preferences so that I would do something like
"gnome-open foo.c", and it would use the user's default editor which
he had setup in Gnome.

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

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.

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

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?

Here is my list:

- install multiple versions of the same apps
- allow user's to install applications (no superuser required)
- 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)
- separation of 'immutable' (i.e. part of the distribution) app
  data from 'mutable' data. 

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.

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

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net