On Wed, May 8, 2013 at 12:52 AM, Marco d'Itri <m...@linux.it> wrote: > On May 07, Jonathan Dowland <j...@debian.org> wrote: > >> > If we do this, I'd prefer to make /usr a symlink to / on new installs >> I've always thought that myself, but it seems most folks who are pro >> merge tend to propose going the other way. I've never understood why. > I was trying to not start a new discussion about this, but since you > asked: moving /usr in / does not solve any significant problem, while > moving /{bin,sbin,lib} to /usr allows some very interesting new things > like being able to have a truly shared stateless /usr containing the > whole OS, which can be used for things like appliances which can then be > upgraded and rolled back with a single rename(2). > > The Fedora page explains some: > http://fedoraproject.org/wiki/Features/UsrMove >
I support doing /usr move, for it can help on making better use of snapshot function of BTRFS/ZFS. An easy example is that, on Solaris, there is a something called boot environment (BE), which is essentially snapshots of the combination of /usr and /boot, users can switch between different BEs easily without affecting any user data. Without /usr merge, doing such work could be much more complicated because user data and system data is mixed in the file system's hierarchy, it's hard to make sure switching between different snapshots won't change user data. While if such thing is done properly, then user won't be bothered about messing up the system on upgrades or experiments anymore. They can switch among different working environments easily, without dealing with the odds caused by multi-boot. There is apt-btrfs-snapshot around for some time (hasn't been in Debian, yet), and it can be relied upon in production systems only when the separation of system data and user data is done. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w6enqh2uphthhezupggq0oj_hftm32ufunipbcpwki...@mail.gmail.com