Subject: Re: /var/db/pkg
To: Robert Elz <kre@munnari.OZ.AU>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 05/25/2000 21:55:36
On Thu, May 25, 2000 at 07:05:54PM +1000, Robert Elz wrote:
> Date: Thu, 25 May 2000 10:23:12 +0200
> From: Manuel Bouyer <email@example.com>
> Message-ID: <20000525102312.A14296@antioche.lip6.fr>
> | This assume you're running a stock release :)
> yes, that's what I thought we were talking about...
> | There's at last one important thing in /: the kernel.
> That can be one of the saved files, if you need it. For me, just saving
> the arch/xxx/conf/XXXX file is sufficient, I can always just build a
> new kernel.
Slower than restoring from backup
> | I also have
> | custom stuffs in /, and not all important files in / are in /var/backup
> | (or you have to copy the whole /etc).
> Sure, you just add those to the list of saved files. You customise,
> you do a bit more customising...
> | Why ? I can restore from tape elsewhere and copy over NFS.
> Speed is one reason. Lots of things are possible, but doing an
> install (esp from a fast CD) and copying a few files back into root
> beats anything I've seen - esp as anything that reconstructs root
> needs half the install done anyway (newfs, probably labelling, ...)
Depends on the machine you have to restore :)
> | Then you know what you're doing. I use fetchmail/procmail, and all my mail
> | ends in $HOME.
> For fetchmail it depends how you run it, so people prefer it to just
> get the mail from the server, and dump it into the local MTA
> (sendmail/postfix/ ...) which will then by default put it in /var/mail
Then this mean you can't work on any other machine than your own. I don't
setup things this way :)
> For procmail, sure, generally mail goes in $HOME, but where do you think
> procmail saves the mail when $HOME is full?
Where you told it to save.
> | Depends on what you're using dhcpd for. Anyway it's not on all machines.
> yes, exactly. The point is that it would be a very poor idea for NetBSD
> to start giving people the impression thatdumps of /var are a not needed.
> There's too much that might be depending upon them. And explicitly moving
> stuff out so that dumps might not be needed for person X gives that impression.
I maintain, a backup of the *system* shoudl't require /var. libc.tags or
db/pkg is part of the system.
> | 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).
> Somewhere? Where. In general, anything that the system creates, and
> wants to keep, should be in /var. /usr is for what comes off the
> distribution is a better model (with /usr/pkg for packages, and /usr/local
> for scribbling in...)
The system doesn't create these, they're part of the system (they're there
at install time).
> | 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).
> For me it is just the opposite, /var (with its copies of what is in /)
> is the definition of the system, it and any user files that might happen to
> exist are all that really matters, the rest is all distribution stuff.
> I only rarely backup /usr - nothing there changes. I "make package" when
> I build from kgsrc, and save the packages, so they're easy to replace, aside
> from that, and /usr/local (which is a mount point...) /usr is just what
> came from the distribution, no changes at all.
So for you too it would be more consistent if db/pkg was with /usr/pkg :)
Manuel Bouyer <firstname.lastname@example.org>