Date: Sun, 18 Sep 2016 17:38:19 -0500 From: Brandon J. Wandersee <brandon.wandersee@gmail.com> To: "Kevin P. Neal" <kpn@neutralgood.org> Cc: "Brandon J. Wandersee" <brandon.wandersee@gmail.com>, Matthew Seaman <matthew@FreeBSD.org>, freebsd-questions@freebsd.org Subject: Re: 10.3 zpool/var canmount = off? Message-ID: <86intsg7fo.fsf@WorkBox.Home> In-Reply-To: <20160918201546.GA6277@neutralgood.org> References: <CA8E95A8-DFBA-488D-9060-1F2694E146EF@gmail.com> <4bd29396-220a-e198-73b9-0de91b74d096@FreeBSD.org> <86d1k3tufs.fsf@WorkBox.Home> <20160918201546.GA6277@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin P. Neal writes: > On Fri, Sep 16, 2016 at 04:18:31PM -0500, Brandon J. Wandersee wrote: >> >> Matthew Seaman writes: >> >> > The point of having zroot/var (with canmount=off) that just acts as a >> > placeholder is so that eg. zroot/var/log or zroot/var/tmp (which you'll >> > see have 'canmount=on') get mounted in the right location in the file >> > system without becoming part of any boot environment. That means >> > there's only one copy of those filesystems and it always gets mounted >> > every time you reboot -- which is really what you want for eg. /var/log >> > but not correct for boot environments in general. Usually you'll have >> > several available, but only one of them should be mounted and active. > >> I have a tree of >> filesystems for everything related to ports/packages except distfiles, >> so I can roll everything back in lock-step if an upgrade goes bad while >> avoiding having to download everything again. > > Does anyone know for certain that a pkg'ized base system will kill the > ability to keep the base system distinct from /usr/local? > > I keep my /var/db/ports and /var/db/pkg trees symlinked so they are in > /usr/local to guarantee that they are always in sync with the software > that is installed. But a pkg'ized base kills my ability to keep /usr/local > correctly accounted for while doing a fresh install of base, say, in a new > ZFS dataset. Assuming I understand you correctly: it seems one of the things keeping pkgbase out of the mainline right now is the need to update pkg(8) to handle base and application package installation, upgrade, and removal processes separately (e.g. `pkg delete -a` will destroy the system, `pkg upgrade` will upgrade both system and application packages, etc.). It's an acknowledged problem, but I don't know how far along the work is right now. Surely something is being done about it, or folks who upgrade RELEASEs from source or track development branches, while using packages instead of ports, will wind up with broken systems. https://wiki.freebsd.org/PkgBase -- :: Brandon J. Wandersee :: brandon.wandersee@gmail.com :: -------------------------------------------------- :: 'The best design is as little design as possible.' :: --- Dieter Rams ----------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86intsg7fo.fsf>