Le 27/01/2023 à 22:06, karl@??? a écrit :
> Altoid:
> ...
>> Is it at all necessary or is it like systemd, another one of LP's
>> missions to screw up everything Linux that his acolytes insist on
>> shoving down our throats?
>>
>> Maybe it is time to revert this /usr merge thing and carry on as we
>> were before someone had this bright idea than no one seems to want to
>> put to use.
> There is an old thread somewhere describing how people on debian
> tried to keep the /usr split, but since more and more thing being
> entangled in each other that made that painful (in some sense).
> Also there was descriptions of strange connectivity thing involving
> wifi networks.
>
> So there seems to be some honest work done but it was deemed
> fruitless.
>
> My guess that the /usr merge is to handle (from a distributers view)
> all kind of installations in a sane manner, especially for laptops.
>
> For a stationary box, the only thing I can think of is new and more
> dependancy of libs, regardless if you need them or not.
>
> Regards,
> /Karl Hammar

    Because they do all the work, I consider distros may have serious
motivations to change the file system hierachy. But I'm not sure that
all the consequences have been considered and I am concerned that this
causes some confusion. I consider that the /usr merge should leave /bin,
/sbin and /lib free for the admin to use at her/his will.

    There is a risk that some upstream developpers still hardcode the
old FHS, and this makes it necessary to have /bin and /sbin symlinks to 
their counterparts under /usr. This, in turn, would prevent the DIY
admin to install alternative tools in /bin and /sbin, in particular
applications needed for a custom early init sequence replacing the
initramfs of the distro.

    For example, if one installs a static Busybox in /bin and /sbin,
all the base Unix and Linux applications are available but their syntax
is often slightly different of their Gnu equivalent, because they try to
strictly comply to POSIX, therefore rejecting a bunch of Gnu extensions.

    In addition, care must be taken to properly define the PATH. After
the /usr merge, neither the system tools and services, nor the normal
user sessions should include /bin and /sbin. I mean if they expect to
use Gnu commands.

    Therefore I consider that a counterpart to forcing the /usr merge
should be to carefully ignore /bin, and /sbin. But I'm afaid this
strategy of consistency is in contradiction with the efforts to keep the
merge reversible.

--     Didier