On 2011-10-12, Marco d'Itri <m...@linux.it> wrote: > > --zx4FCpZtqtKETZ7O > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Oct 11, Sven Joachim <svenj...@gmx.de> wrote: > >> >> We already discussed the idea of dropping support for a separate /usr, >> >> and the outcome was a broad consensus for keeping things this way. >> > No, we discussed the idea of merging /usr in / (to which I was opposed >> > myself as well). >> > This is a different concept. >> I think Joss is referring to the thread you started at >> http://lists.debian.org/debian-devel/2009/05/msg00075.html and the >> conclusion you came to in >> http://lists.debian.org/debian-devel/2009/05/msg00935.html. > I am aware of what he is referring to, and it is still a different > thing. > > So let's look at the reasons against merging /usr in / listed in my > final summary. All of them do not apply to merging / in /usr, and > actually become arguments in favour of doing it: > - NFS: sharing a read only system over NFS becomes much easier (I would > say that it actually becomes possible...)
And if NFS happens for whatever reason, be down when you try to mount /usr, you have a useless system since you can do nothing with it. > - junk hardware: while moving /usr to / may not be possible due to the > small size of the root partition, moving / to /usr will be easy > - read only system: more parts would be read only ? Surely you can make whatever you want read only now. > - dmcrypt: more parts would not need to be crypted, if desired > > And then there is the big argument in favour of it: booting without /usr > is becoming more and more difficult. The two current solutions for this And this would make it impossible. > adopted by udev and the related tools are both suboptimal: waiting in a > loop for /usr to appear can fail due to the timeout (and I wonder when > we will hit the first deadlock), and moving even more stuff from /usr to > / can work only up to a point. > It is completely unclear what is pushing this proposal. Also initrd or initfsrd both make things far more obscure--it seems to me it becomes more difficult to figure out what your boot is doing, and how to fix it when things break. And sometimes things break. -- 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/slrnj99rg0.s60.un...@wormhole.physics.ubc.ca
