On Thu, 25 May 2000, Manuel Bouyer wrote:

# Date: Thu, 25 May 2000 10:23:12 +0200
# From: Manuel Bouyer <bouyer@antioche.lip6.fr>
# To: Robert Elz <kre@munnari.OZ.AU>
# Cc: current-users@netbsd.org
# Subject: Re: /var/db/pkg
# 
# On Wed, May 24, 2000 at 06:20:33PM +1000, Robert Elz wrote:
# >     Date:        Tue, 23 May 2000 18:01:37 +0200
# >     From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
# >     Message-ID:  <20000523180137.B357@antioche.lip6.fr>
# > 
# >   | I disagree. /etc is where up-to-date files are stored, this is what's
# >   | important.
# > 
# > yes, it is, but if you do
# > 
# > 	dump ... /
# > 
# > or
# > 	cp /etc/{files,that,matter} /var/backups
# > 	dump ... /var
# > 
# > then surely all that matters is saved just the same, except there are
# > several advantages.  (Or you can use some other directory in /var,
# > I have used /var/save sometimes) if you perfer to leave the standard
# > NetBSD usage of /var/backups unaltered.
# > 
# > First, should one of the important files be lost, it is just left sitting
# > there in /var just the same as it is on the tape, which can make it much
# > quicker to recover.   Second, more useful stuff gets dumped (most of the
# > rest of the dump of / just duplicates the distribution, and isn't really
# 
# This assume you're running a stock release :)
# 
# > important, essentially nothing in /var is of that nature), and third, if
# 
# There's at last one important thing in /: the kernel. I also have
# custom stuffs in /, and not all important files in / are in /var/backup
# (or you have to copy the whole /etc).
# 
# > you need to do a full restore, then you can't really start with a full
# > restore of / - you need / to exist in order to do the restores.  It is
# 
# Why ? I can restore from tape elsewhere and copy over NFS. I've done this
# a lot of time (not only to restore a server, but also to duplicate a server).
# 
# > generally easier to re-install in that case (perhaps even upgrade) and
# > then restore /var and copy back the files that matter.
# > 
# >   | /var/mail is only on mail servers,
# > 
# > Not true.   If you use fetchmail, or even procmail, your mail (or some
# > of it) can end up in /var/mail even on your local workstation.
# 
# Then you know what you're doing. I use fetchmail/procmail, and all my mail
# ends in $HOME.
# 
# > 
# >   | If you're backuping once a day, /var/spool/mqueue and /var/db/dhcpd.leases
# >   | will be out of date anyway and are not that usefull.
# > 
# > mqueue varies - though recovering it is generally better than trashing it
# > if at all possible (some messages can wait in the queue for days before being
# > delivered).   For dhcp.leases, unless you have a very high churn rate, it
# 
# On internal mail servers it's there at most one day, usually.
# 
# > will always be much better to recover it.   In most cases (where there are
# > enough addresses available for the clients), even an out of date leases
# > file is much better than none at all.  The dhcp server will hand out the
# > same address again to a client that requests it, even if the lease had
# > expired (or the server thought it had because of an old leases file being
# > restored), which is just what you want to happen.
# 
# Depends on what you're using dhcpd for. Anyway it's not on all machines.
# 
# > 
# >   | On a system where /var matters I'd rather go with a raid filesystem than
# >   | backups.
# > 
# > Sure, mirroring (or raid 5 or whatever) /var is a good idea for continuous
# > uptime - but that is no substitute at all for dumps.  No raid I have ever
# > seen will recover you from a major machine room fire...
# 
# Sure, in this case I don't matter much about the dhcpd lease file :)
# 
# > 
# >   | Conforming to hier is also important I think:
# >   | /var/      multi-purpose log, temporary, transient, and spool files
# > 
# > hier is a description of what is where, it isn't, and shouldn't be,
# > treated as a specification of what must be put where.
# > 
# >   | /var/db/pkg doens't fit in this category.
# > 
# > Nor is /var/at, yet hier(7) (the 1.4.2 version anyway) says that
# > goes in /var ...  It does with /var/msgs as well.  Then there's
# > also /var/spool/ftp.
# 
# If a server is reinstalled from backups I would't expect at jobs to be
# restored. However I agree that crontabs should not be in /var as well
# (but this is less annoying for me than /var/db/pkg :)
# 
# > 
# > I think the one line summary of /var is a poor one, it is an attempt to
# > describe what is a general mish-mash really by example, which is a very
# > poor way to accomplish anything useful.
# > 
# > I'd prefer if hier(7) said
# > 
# > 	/var/	system maintained files that are subject to change
# > 		(including spool, log, database, and longer term
# > 		temporary files)
# 
# I don't find that /var/db/pkg fit in this sheme very well anyway.
# It's not the same as the other stuffs in /var/db (Hum, there's libc.tags
# here too, should be somewhere in /usr IMHO).

At the risk of sounding like a dinosaur, with the way we're proposing to
gut /var's original purpose (which IS the place to hold the package
database, btw -- if you want to export it RO, do so, but I think it's
perfectly fine where it is!), gee, maybe we should just get rid of /var
altogether.

I think that it would be a damn shame to step back into the mire from
whence we have tried to evolve.

Why put the db/pkg stuff in /usr?  Christ, LINUX puts *everything*
in /usr, wants to put /usr under root.  I, for one, LIKE the way the
stuff is laid out thus far -- it's in a nicely PURPOSEFULLY segregated
fashion.

I'd hate to see this proposed change enforced.

# On most systems I don't care about what's in /var where I care about / or
# /usr (and this is the case for most workstations or developement machines).
# But I have to backup it because there are stuffs here associated with
# things of /usr. Such stuffs should be in /usr as well IMHO.
# For sure a simple symlink will fix it but I'd prefer if the default was
# changed :)

I'd prefer it was _configurable_.

A lot of zealous people out there are forgetting that when they decide to
exact their opinion on process, especially if it's not a flexible solution,
they can make life absolutely miserable for anyone else who does not
agree with that solution.

If the flexibility is put in to configure it on a per-site basis by way
of a less heinous kludge than a symlink (hint: this is why we have
VARIABLES and CONFIG FILES), you'll achieve your desired result easily
and you'll upset far fewer people.

And as for the silly get who keeps insisting that splintered config files
for rc stuff are easier to maintain than a single centralised file, I have
one question:

"What are you smoking?"

# 
# --
# Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
# --
# 


				--*greywolf;
--
BSD: My Computer Runs!