Re: Alternate installation paths

[Kjetil Ødegaard <kjetilod@xxxxxxxxxxxxxx>]

Even if the reasons for /var/qmail no longer seem pertinent, changing it
now would solve nothing, and destroy any benefit this setup has ever
had.

* Jens Benecke <jens@jensbenecke.de>
>
> _Every_ program is supposed to have machine-specific, user-global
> configuration in /etc. Really global data and configuration files
> (which usually get overridden on user (~) or machine (/etc) basis)
> belong in /usr/share.

Excepting, of course, locally compiled packages, which put files in
/usr/local/share, /usr/local/etc, etc---which means that without knowing
where a package came from, you have no idea where it might keep its
files.

> > > C) Qmail is one of the very few programs that break the expectation of Unix
> > > sysadmins that binaries go in bin,

A standard BSD system has a number of binaries in directories like
/usr/libexec and /usr/games.  Lots of people install software in
directories like /usr/local/apache and /usr/local/samba.

> > Which bin?  /bin?  /usr/bin?  /usr/local/bin?  /opt/bin?  (etc.)
> 
> Simple enough. One of the ones that were made for the purpose.
>
> /usr/bin	for programs that are _not_ needed for booting and
> 		setting up the system (because /usr can be NFS) and are
> 		used by users. e.g. xemacs, gcc, etc.
> 
> /usr/local	for stuff you compiled yourself, so that it doesn't
> 		interfere with the packaging system, or which is
> 		specific for some systems ("local software"), if /usr
> 		isn't NFS
> 
> /opt		for binary stuff that has its own directory structure, 
> 		e.g. StarOffice, or commercial software, and that 
> 		doesn't come in source form. "optional software"

You do realize the benefit of making these distinctions is based upon
the inability of your package manager to properly handle software which
doesn't come pre-packaged by your vendor?

> > > configuration in etc,
> > Which etc?  /etc?  /usr/etc?  /usr/local/etc?  /opt/etc?  (etc.)
> 
> There is only one /etc.

Maybe there is, on your machine.  However, those files may reside in
completely different directories on other computers.  Accessing
/etc/wgetrc on my computer, for instance, will fail; the wget package is
compiled locally and has its files under /usr/local.

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

If a package has constant names, almost all of these problems go
away---there simply is no need to search for the file.  As for the
convenience of PATH, this problem can be adequately addressed by using
symlinks.

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

To successfully remove qmail, you will have to stop your system from
automatically running qmail-start and qmail-smtpd upon boot.  For most
people, this consists of removing two symlinks in /service.

Removing daemontools is a separate issue; other packages may be
depending on it.

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

Standards are for solving problems.  It's a pity when they don't.

> > However, qmail isn't just one monolithic program with a single
> > configuration file.  When you have multiple programs that have to call
> > each other to process a single message end-to-end, it's a Good Thing
> > to be assured that each component looks for each of its configuration
> > files and its sibling components at a fixed location.
> 
> Yes. And other programs have to be able to call qmail. And qmail has to
> be able to call other programs. So why not rely on the system to find
> them? Call "qmail-queue", and let $PATH figure out where it is. This is
> easiest if $PATH is fairly small.

Because relying on PATH provides no benefit if the packages have
constant names.

> You are considering that all people will run is qmail, on 1000 different
> boxes. If that is indeed the case, you are probably right, it is simpler
> to install everything in the same place (though why that should be in
> /var/, I don't know).

It benefits not only you, but every person having to do with your
system, such as people providing support.

> And even with 1 app running on 1000 systems, which administrator will
> choose 1000 completely different systems? It would be suicide. Choose
> 1000 identical systems and set them up to mirror each other's setups,
> except for strategic configuration files. Much easier, especially if you
> can find all configuration in /etc.

If the configuration files on your computers instead are in
/var/qmail/control, which also happens to be the place where they reside
on every other qmail system on the planet, what have you lost?

> > It's even more useful if /you/ are the outside help.  Example: Your
> > client has /etc/qmail/locals and /usr/local/etc/qmail-locals on his
> > Red Hat system, both of whose contents are in the control/locals
> > style.
>  
> > [1] Which one is being read by his qmail setup?
> 
> If he didn't screw up completely (in which case I'd tell him to better
> run qmail on WinXP, just for kicks): The /etc one by the qmail suite
> that was installed by RPM, the /usr/local one by the qmail he compiled
> himself.
> 
> And if this isn't obvious, there's always strace. Or installing Debian.
> ;)

These are non-solutions;  you are unable to distinguish between a
vendor-provided package and a locally compiled one.

> > [2] How do you know?
> 
> How do you know the old sysadmin hasn't patched qmail2 to read 
> 	"/home/..               ./.. ./foo"
> because he or she thought it would be cool?

"How do you know the old sysadmin hasn't removed /bin/sh because he
though it was cool?"

> Why shouldn't you re-use the binary files from one qmail installation in
> a second, if you really _need_ two installations? For the second one,
> e.g. set $QMAILDIR or whatever, and be happy.

Right.  Of course, QMAILDIR should be set in the system-wide
configuration file /etc/environment.  Naturally, applications should not
rely on this filename, but instead look in the hashed /etc/registry.db
file.  We might need to move /etc/registry.db, so the filename is listed
in the variable COMPILEDFREGISTRY, etc.

Read http://cr.yp.to/slashpackage/finding.html for the full story.

> >   Windows: Uninstall requires pkg mgt system (complex framework)
> >   qmail:   Uninstall requires pkg mgt system (complex framework)
> 
> Which Windows doesn't have (and therefore _has_ to do these quirks) and
> doesn't really need (because in Windows nobody in his right mind would
> install thousands of applications on _one_ system).
> 
> But Linux and many other Unix systems _do_ have one and the admin has to
> know it anyway. Why not use it?

Because it doesn't solve the problem.

> All I need to duplicate my setup (except user data) is a copy of /etc, a
> list of packages that were installed, and an installation CDROM. There
> are no hidden files, secret packages in non-standard locations or
> whatever. This is the case with every FHS-compliant Linux system, and it
> makes life really easier.

Excepting (again) locally compiled packages---you'll have to wait for
your vendor to package them (if ever).

> I don't really *care* where a program installs. What I care about is
> that I can expect to mount /usr readonly (as intended), or via NFS, and
> that I can safely leave most of /var out of backups, because just about
> everything there can be or will be regenerated, and so on.
>
> If there is one application that jumps out of the line, it destroys all
> these expectations and makes system maintenance much harder.

qmail doesn't hinder you in mounting /usr read-only, and the only backup
you'll need is a copy of /var/qmail/control.  What's your point?

-- 
Kjetil