Re: Gnome/Linux Application Installer

[David Jeske <jeske home chat net>]

On Wed, Dec 23, 1998 at 06:25:22PM -0700, Jason Nordwick wrote:
> >On Wed, Dec 23, 1998 at 04:57:44PM -0700, Jason Nordwick wrote:
> >> My concerns.
> >>
> >> 1. Gnome is not only GNU/Linux, what about the BSDs and other Free
> systems?
> >
> >Agreed.. that's why the proposal I made is doable on all unicies. It's
> >patterened after the nextstep solution which was done on BSD.
> 
> So, are you saying that GNOME should have it's own install seperate from the
> normal installation software shipped on the machine already?

What I'm saying, is that we should take a good hard look at what parts
of "getting an app to work" _should_ happen during the install, and
what parts shouldn't. 

To quote myself from the message at this URL:
http://www.gnome.org/mailing-lists/archives/gnome-list/1998-December/1578.html

  "I agree with all these needs. I think one of the best ways to
  achieve these goals is to change the responsibility of the 'install'
  itself. Currently, a program install is responsible both for
  'copying an app's files onto the system' and 'plugging that app into
  the system's configuration'. If we redefine install as 'copying an
  app's files onto the system' and 'publishing what exports an app has
  which _might_ be tied into the system configuration', I think we can
  make this significantly cleaner."

I think some of the confusion comes from overloaded terms. 

To answer your question above, I don't think that Gnome should be
replacing rpm or dpkg, or any of the current install programs. They
can exist and do the job of copying files onto the system. I think
that Gnome should define the 'shape' of an installed application in
the filesystem, and the APIs an application uses to get at it's
datafiles in an install-location independent way. 

Someone has to make these changes to how applications are developed,
or the package managers arn't going to be able to fix the install
location dependencies. I think Gnome is as good a place to do it as any.

> The two main impacts to my statement were that (1) the package system should
> integrate with the system wide model and (2) it should look consistant with
> the current system.

(1) Any standards we make for laying out applications and having
applications find their data will only improve the capabilities of
existing package systems. In a sense, I'm advocating defining a new
way to handle 'modern applications', instead of the old UNIX
"/usr/local/bin, /usr/local/lib" style.

(2) I don't know what you mean here, can you clarify.

> >If you don't agree with what I said above, consider that no amount of
> >package system magic will fix the fact that applications in UNIX have
> >no way (presently) to find out where they were installed. Until we fix
> >the _applications_ (by fixing the standard libraries) package managers
> >are helpless.
> 
> Just because an application does not know where it is installed, there will
> always be these problems?  

Apps hardcode install locations, this causes many problems. Part of
the reason they do it is that there _is no standard way_ for them to
find out where they are installed. UNIX just wasn't designed for this.

However, this is only one problem of many. Other ones include problems
registering filetypes and icons. "wmconfig" is another solution with
problems, because it again relies on having root privileges and
running scripts. I address how we can solve all these problems in the
message that the above URL points to.

> Yes, I see this as a small problem, but I think that there is a jump
> in logic to saying that this problem will fail all package systems.

If an application is hardcoded to expect to see it's datafiles in
"/usr/local/gnome/lib", how is a package system going to allow it to
be relocated?  It can't. It's (currently) not the responsibility of
the package installer to deal with the run-time issues of finding it's
datafiles. In fact, in UNIX, there is no code or layer responsible for
connecting an app to it's datafiles, that's the core of the whole
problem.

Until we admit that we need this layer, and we provide it, the
problems will persist independent of what package system you use. I
believe that Gnome is an appropraite place to do this.

If you believe otherwise, then explain to me how a package system,
with today's hardcoded apps, is going to allow me to:
  1) install multiple versions of the same app
  2) install an app without having root privileges

> I do agree that applications need to be fixed, but the fixes are not solely
> technical, but also teaching people how to do things in a system independant
> manner (e.g., I saw a program where in order to get the applications name,
> instead of lookin at argv[0], it looked at /proc/<pid>/cmdline (or whatever
> it is called) and parsed that, blah... But that is whole different argument
> on the Linux gratiutous procfs).

We should provide an abstraction API to have apps find their datafiles
(i.e. install location) on all platforms as part of Gnome. 

> There are a few groups working of different packages systems, I just think
> that we should look at all the alternative before jumping to a current
> broken model, which it seems that you do agree with me: current package
> managers are broken).

I agree that 'application management' on UNIX is currently broken. I
argue that there isn't anything you can do with a package manager, in
the existing unix concept of package managers, which is going to fix
this.

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