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 <bouyer@antioche.lip6.fr>
>     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 <bouyer@antioche.eu.org>
--