On 2015-12-09 05:53, Duncan wrote:
> Christoph Anton Mitterer posted on Wed, 09 Dec 2015 05:36:37 +0100 as
> excerpted:
> 
>> On Fri, 2015-11-27 at 01:02 +0000, Duncan wrote:
>> [snip snap]
>>> #2 The point I was trying to make, now, to mount it you'll mount not a
>>> native nested subvol, and not a directly available sibling
>>> 5/subvols/home, but you'll actually be reaching into an entirely
>>> different nesting structure to grab something down inside, mounting
>>> 5/subvols/root/home subvolume nesting down inside the direct
>>> 5/subvols/root sibling subvol.
>>
>> Okay so your main point was basically "keeping things administrable"...
> 
> =:^)
> 
>>> one of which was that everything that the package manager installs
>>> should be on the same partition with the installed-package database, so
>>> if it has to be restored from backup, at least if it's all old, at
>>> least it's all equally old, and the package database actually matches
>>> what's on the system because it's in the same backup!
> 
>> I basically agree, though I'd allow few exceptions, like database-like
>> data that is stored in /var/ sometimes and that doesn't need to be
>> consistent with anything but iself... e.g. static web pages
>> (/var/www)... postgresl DB, or sks keyserver DB... and so on.
> 
> Of course.  But such data isn't usually managed by the package manager, 
> so splitting off a partition or subvolume or whatever, is fair game.
> 
> IOW, /var can and should still be on /, but /var/www and the like can be 
> on some other subvolume or filesystem.
> 
Agreed.  It's not too bad fixing a Gentoo system (as long as
/var/lib/portage/world is still correct, you can just nuke the installed
package database and emerge world, it'll take time, but it will get your
system in a guaranteed consistent state).  On something using dpkg or
rpm though, it's got the potential to be almost impossible to recover
from without a significant amount of low-level knowledge of the package
manager's installation database.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to