What, if any, is the benefit of squashing /usr out of the equation? I
happen to have a few workstations that load their /usr off an NFS share
presently, with some bodgery-workarounds I did pre the udev notification
about initramfs's which I have never got around to implementing
(although I'm pretty sure I have the tools now to do, along with UUIDs
for boot media).
Whilst these aren't currently scheduled for upgrade, I don't personally
see any merit, given discussions here about work needed to 'shore up' a
change to match some particular use case. I would therefore definitely
agree with those that have proposed that this is an Option and not a
standard gentoo install item unless there are some specific caveats that
this solves.

Michael/veremit.

On 05/04/16 02:19, William Hubbs wrote:
> All,
>
> I thought that since the usr merge is coming up again, and since I lost
> track of the message where it was brought up, I would open a
> new thread to discuss it.
>
> When it came up before, some were saying that the /usr merge violates
> the fhs. I don't remember the specifics of what the claim was at the
> time, (I'm sure someone will point it out if it is still a concern).
>
> I don't think creating usr merged stages would be that difficult. I
> think it would just be a matter of creating a new version of baselayout
> that puts these symlinks in place:
>
> /bin->usr/bin
> /lib->usr/lib
> /lib32->usr/lib32
> /lib64->usr/lib64
> /sbin->usr/bin
> /usr/sbin->bin
>
> Once that is in place in a new baselayout, I think portage's colission
> detection would be able to catch files that had the same names and were
> originally in different paths when building the new stages.
>
> I put some thought also in how to nigrate live systems, and I'm not sure
> what the best way to do that is. I wrote a script, which would do it in
> theory, but I haven't tested because I only have one system and if
> it breaks it the only way back would be to reinstall.
>
> The script is attached.
>
>
> Thoughts on any of this?
>
> William
>


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to