Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
Johannes Schauer Marin Rodrigues:
> Quoting Michael Biebl (2021-07-19 15:10:42)
>> [...]
>>
>> According to
>> apt-file search -x '^/(lib|bin|sbin)'
>> on my Debian sid/amd64 system, we have 1747 packages shipping 24583
>> files in those directories.
>
> more precisely, on amd64 unstable:
>
> /bin 247 files
> /lib{32,64,x32} 83 files
> /lib/firmware 2379 files
> /lib/live 115 files
> /lib/modules 17500 files
> /lib/systemd 2221 files
> /lib/udev 614 files
> /lib/x86_64-linux-gnu 343 files
> /lib/* 441 files
> /sbin 547 files
>
> So most files come from /lib/modules, where only 14 packages are involved,
and debhelper's dh_installmodules that will need to be tweaked to look
into /usr/lib/modules as well.
But I have no idea if/when we would be ready for that and I will not
be changing debhelper until we are ready to move these bits to /usr.
Likewise for udev, here dh_installudev still uses /lib/udev and will
continue to do so until I know that udev also checks /usr/lib/udev.
If you are involved in udev or/and /lib/modules and know that they are
ready to move to the relevant directory under /usr, then please feel
free to file a bug against debhelper requesting that the /usr directory
will be used in the future.
Please do also note in that bug report whether you also want debhelper
to automatically migrate existing files from /lib to /usr/lib. This
should only be the case where we expect (almost) zero breakage from an
automatic "unordered" transition.
(NB: Please use a bug report as I will first be implementing this after
the bullseye release and rely to this thread is likely to be lost in my
inbox)
> /lib/systemd which will be fixed by an update to dh_installsystemd, and
Indeed, I have heard this request and the systemd maintainers confirmed
to me that systemd in bullseye checks both /lib/systemd and
/usr/lib/systemd.
I have a branch lying around trying to support this. The main key
feature missing is the migration of /lib/systemd -> /usr/lib/systemd
(which needs to handle that both exist and merge them into one somehow).
> /lib/firmware where only 36 packages are involved. The remainder then doesn't
> sound so scary anymore as it only involves 656 unique packages and not 1747.
> And again many of those remaining packages will be fixed by an update to
> debhelper, correct? Given that 90% of source packages use dh, that would reduce
> the number to a very manageable size.
>
Indeed, about 90% of all packages uses dh according to trends.
Though for good measure I thought I would explicitly answer the proposal
(from another mail in this thread) that debhelper could move everything
from /lib to /usr/lib:
No, I will not support an unconditional move from /lib to /usr/lib
via debhelper during bookworm.
There are already two distinct examples in this thread for how this
could break things. I will be sticking to "targeted" migrations where
the major consumers have informed me that they are ready to support the
migration.
>> [...]
>>
>> Once we have this global switch to merged-usr, packages can bit by bit,
>> completely independent, update their debian/rules to use --prefix=/usr
>> and after a few years, we don't have any packages anymore installing any
>> files in /. We could aid this process with a lintian check that flags
>> packages that install files in /(sbin|bin|lib)/.
>
> So what what is actually the roadmap after the bullseye release? What is the
> way forward? Should I rather file bugs with patches against individual packages
> to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we
> already have a debhelper patch to do that move for us?
>
For some, debhelper will your problem but there will packages that will
need manual migration. As I see it, there will *not* be "the debhelper
patch to fix them all" - even if there will /some/ debhelper patchers
that will fix "most of them".
Related, I have no intention of supporting / maintaining a rewrite of
"--prefix/PREFIX" parameters to configure/make/cmake or whatever. (Not
saying anyone proposed it - but mentioning it as another "there will
definitely be manual clean up" data point).
~Niels
Reply to: