Re: Alternate installation paths

[Marcus Bointon <marcus@synchromedia.co.uk>]

on 3/3/2002 8:05 pm, Jens Benecke at jens@jensbenecke.de wrote:

>> OTOH, consider how much work your favorite package management system
>> has to do to uninstall or otherwise keep track of a single package
>> that was designed to go "splat" across several directories common to
>> all the other hundreds of packages on the same system.  A single
>> package DB corruption could ruin your whole day...
> 
> my problem with every program having its own top level directory can be
> summarized by saying "C:\Program Files".
> 
> How long would your PATH, LIBPATH, LD_LIBRARY_PATH, INCLUDE_PATH, and
> WHATNOT_PATH have to be if every single one of the (let's see) 1213
> packages I have installed currently lived in /var/$PACKAGE,
> /opt/$PACKAGE, /usr/$PACKAGE, /$PACKAGE or wherever the author decided
> it would be fun to put them.
> 
> The problem is that qmail, like just about every other program that
> claims similar things, is NOT 100% in /var/qmail: It needs daemontools,
> which create a /service tree full of stuff. Or init scripts in
> /etc/init.d. It needs uscpi-tcp files in /etc. Extra environment
> variables. inittab entries. It may need cron jobs. Special users with
> special .qmail files. And so on.
> 
> My point is, when you claim removing /var/qmail to deinstall qmail is
> enough, you are wrong, and doing this leaves lots of orphaned files on
> the system.
> 
>> (As an aside, does anyone else find it amusing to see master config
>> files that specify the full pathnames to secondary config files?  Such
>> things are never necessary with qmail's one-place-for-all-my-things
>> approach, as opposed to one-place-for-everyone's-things.)
> 
> That's the problem: If this becomes popular, I would not have one, I
> would have 1213 place-for-all-my-things. 1213 /usr/$FOO/bin entries in
> my PATH. 1213 subdirectories under /usr - or worse, only 609 in /usr,
> the rest scattered over /var, /usr/opt, /opt, etc. because author and/or
> packager felt like it.
> 
> And, additionally, it makes implementing NFS properly impossible. There
> are user-specific (~), machine-specific (/etc, /boot), architecture
> specific (bin, lib) files, global files (/usr/share, /usr/include), and
> so on. If those are grouped together, you can administer a NFS network
> with ease. If you need to make each application "network capable"
> seperately, like with Windows, you will die before finishing.
> 
> It's better to make life easy for 98% of 1213 programs, than for 100% of
> 1 program. That's what standards are for. Pity we have so many.

Just wanted make an "alternative" observation: Knock it all you like, but
"classic" MacOS handles all this in a very elegant way: There are no paths,
nor any need for them.

I can move files from one volume to another, rename directories and files
and have essentially zero impact on the system or user experience. Files are
tracked by unique id, not by filename or location. A filename is metadata,
in exactly the same way that file type, creator, permissions, MIME type,
modification date or user comments are. For the same reason, the equivalent
of windows shortcuts or symbolic links are almost impossible to break for
the same reason (I can even email someone a link and expect it to work). It
also safely allows some operations that are not possible on other systems,
such as renaming or moving open files - because the filename and path simply
don't matter. I can do the equivalent of renaming /etc to /rhubarb and
rename my kernel (or C:\WINNT) to custard, and it will still boot without a
flicker. It also removes a lot of the need for anything like a registry (as
much information is implicit in the file system and applications), the only
equivalent of which is the system preferences directory which a user (even
an admin) should rarely need to touch, and the desktop database and file
which are maintained invisibly.

At an API level, there are calls to get a handle on folders with specific
purposes, so if I want the system prefs folder, I can ask for it and be
given a handle to the appropriate location (this is great for
internationalisation). Would it not be a good idea to implement a similar
(but path-based) mechanism for *BSDs? Rather than assuming that settings are
in /etc, I could ask the system at install time where my settings files
should go. There would be a default set of locations for a given OS
(allowing installation packages better self-configuration across platforms),
but these could be changed at will, so for example, I could keep a second
system setup in /etc2 and switch to it with a single call (hmm, and perhaps
a reboot!), assuming anything that wanted to access a file asked for the
location through the API in the first place of course. Assumed paths are at
the core of most of the problems described, though this doesn't really deal
with different launch mechanisms like rc.conf, inetd, tcpserver, supervise
etc.

Incidentally, I have 1,523 apps installed on my Mac, and I've never had a
problem related to paths or file locations, nor do I have long PATH problems
or slow launch times. If I start running out of space on a drive, I can just
move some apps to another drive without breaking anything. I just don't have
install/uninstall problems - even MS apps are well behaved. There is a lot
to be said for this level of transparency when it comes to system
maintenance and reliability, as you have noticed.

In the traditional MacOS application model, an application is a single file,
so install & uninstall are academic propositions (especially since the
system has no paths to worry about). In reality, the migration of "DLL Hell"
from Windows has damaged this purity for the sake of cross-platform
availability, but it still mostly works. Strangely enough it's Microsoft
that have come up with the most elegant installation for DLL-encumbered
apps, quite unlike the Windows mess.

MacOS X's "packages", borrowed from OpenStep, work by disguising application
folders as single files - kind of like an RPM you never have to unpack. I'm
not sure, but the packaging system may even be available open source in
Darwin.

> PS: I like the calm atmosphere of this discussion. Let's keep it that way.

This is not intended to be advocacy; I'm not suggesting that anyone switch
to MacOS (though OS X is worth a look for BSD types), nor am I denying there
are some downsides, but there are some good ideas in there that should not
be ignored, as they clearly address many of the difficulties that have been
described in this thread (admittedly, by not letting the problem happen in
the first place). Getting them into OpenBSD might be something of a
challenge, however.

Marcus
-- 
Marcus Bointon
Synchromedia Limited: Putting you in the picture

marcus@synchromedia.co.uk | http://www.synchromedia.co.uk