Re: Move all to /usr
On 2011-10-12, Marco d'Itri <md@Linux.IT> wrote:
>
> --zx4FCpZtqtKETZ7O
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Oct 11, Sven Joachim <svenjoac@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.
Reply to: