Re: Gnome/Linux Application Installer

[James LewisMoss <dres ioa com>]

>>>>> On Wed, 23 Dec 1998 18:28:26 -0800, David Jeske <jeske@home.chat.net> said:

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

I don't think an application should be defining where it wants to go
in a filesystem.  I as the user and sysadmin of a machine should be
making that decision.  Under you scheme other than the top level
location of the Application.app (which is NeXTish correct?) I can't do 
that.

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

Easy way: hardcode one location into the app and get all other
information from that.  Actually hardcode two /etc/gnome-defs and
~/.gnome-defs (or whatever is appropriate ~/.gnome/location-defs).

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

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

This is of course in your opinion.  And using loaded words like
"modern applications" and "old UNIX style" attempt to make it look
stronger than it is.

I personally prefer the current method of separating files by function
and not application.  I find this to be a good separation (for example
all files in /usr/share and /usr/local/share can be shared across
platforms (theoretically this is the way it should work), /usr can be
mounted readonly and shared across machines of the same platform, root
level dirs, /lib, /bin, /sbin, /etc are machine local and provide a
means of bringing the machine up when bad things occur.  /etc is not
mounted readonly so that local modifications to configuration can
occur).

Granted there are problems with this scheme, but I think it's be
better to look at ways of improving the scheme rather than introducing 
a gnome only scheme of laying out files.  On my debian system now I
know that I can go to one location, /etc, and modify configurations for 
all installed programs.  I don't have to go searching.

 >> Just because an application does not know where it is installed,
 >> there will always be these problems?

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

Then create one that doesn't fly in the face of good practices.  Using 
a configuration file in /etc and the home directory is one simple way
to fix apps.

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

And why shouldn't the common case involve root privileges?  If the
software is good enough to install in one users (now bloated) home
directory then it's good enough to install for all users.  The user
specific case is dealt with by creating configuration files in that
user's home directory.  This keeps user level configuration separate
from the rest.

But even then it's not too difficult to install an application into a
users home directory and run things from there.  It'll look to the
user specific file location file in the user's .gnome directory.

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

You are of course assuming that this problem can't be corrected in the 
application.  How about a nice standard library for all applications
that need configuration and location data that does all the figuring
out for you?  Would this solve the problem?

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

I don't.  Gnome is a set of applications.  It isn't the machine and it 
shouldn't be making gratuitous changes to how applications are
installed on Unix machines.

 David> If you believe otherwise, then explain to me how a package
 David> system, with today's hardcoded apps, is going to allow me to:

Begging the question.  You are assuming that it has to work this way
when it doesn't.  Under that light the next two questions are simple.

 David> 1) install multiple versions of the same app

Just install them and use different file location config files.

 David> 2) install an app without having root privileges

Answered above.

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

This is a good idea, and doesn't require changes in install locations.

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

If you'd like to list exactly how you think things are broken I'd love 
to argue some more.

I don't disagree that there are problems that need to be fixed.  I do
not think that setting up a completely new way of installing and
locating packages is a good idea.

Dres
-- 
@James LewisMoss <dres@ioa.com>         |  Blessed Be!
@    http://www.ioa.com/~dres           |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach