On 29/11/2018 10:21, Arnt Karlsen wrote:> On Wed, 28 Nov 2018 15:26:59
+0000, Roger wrote in message
> <38625727-08b2-2816-85b0-8f57d679618c@???>:
>
>> This isn't a bug, or even a feature. It's a deliberate design
>> decision which affects the functioning of the system as a whole. I
>> understand your concerns, and I even sympathise with them, but the
>> decision to do this was taken over six years ago after extensive
>> discussion,
>
> ..links to the important parts of those discussions would be nice
> and very helpful.

I don't have the time to dig through all the separate mailing lists, IRC
logs, bug ticket and all the rest. It's scattered too widely and over
too long a period of time. However, I have dug up some public mailing
list threads over the time period concerned which might be informative.

https://lists.debian.org/debian-devel/2011/12/threads.html
Red Hat is moving from / to /usr/
from / to /usr/: a summary

https://lists.debian.org/debian-devel/2011/12/thrd2.html
#652011
#652275

https://lists.debian.org/debian-devel/2012/01/threads.html
from / to /usr/: a summary

https://lists.debian.org/debian-devel/2012/09/msg00010.html
Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/08/thrd2.html
Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/09/threads.html
Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/12/threads.html
Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459
Contains most of the implementation discussion and iterative
refinement of the patchset.

>> and it's been implemented and released six and four years ago,
>> respectively.
>
> ...appearantly with trumpian eptitude, running Karl's usr.pl on my
> "life boat" install of devuan_ascii_2.0.0_amd64_desktop-live.iso,
> I found 20 programs in /bin or /sbin in 12 packages that might need
> a fix.

Interestingly, if you read some of these threads, you'll see people
doing exactly this auditing back in 2011-12 because this was already
causing breakage back then, even before the mounting of /usr in the
initramfs.

> ..I put Karl's usr.pl in /sbin and ran it first bare, then counted
> with: usr.pl |grep ^/ |wc -l
> and: dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort |uniq |wc -l
>
> ..fixing 2 or 3 packages a year, is very doable. ;o)
>
> ..now, do we return to the pre-merge policies 6 and 4 years ago?
> Yes, as a first step, I believe we should[…]

Note that to return to the pre-merge policies would be an exercise in
futility. It was already an exercise in futility back in 2011 because
the number of libraries which /could/ be moved to /lib is an unbounded
set. There's always another tool which /might/ be required, which pulls
in yet more libraries, and their dependencies, and the dependencies of
their dependencies and so on. It's a Sisyphean task.

On 29/11/2018, 06:22 Steve Litt wrote:

> I see the fingerprints of Redhat, Poettering and Freedesktop all over
> such encouragement, and highly doubt it's for technical reasons.

If you read the threads above, you will see that RedHat were planning to
merge /usr at this point. It's no secret that there is some
cross-pollination of ideas between distributions, and that there is also
some degree of pressure for conformity to benefit interoperability.
However, it's also /not/ a conspiracy in any way. This was all
discussed and implemented in public, not done in secret. There were
solid technical reasons for doing this, and it's likely this would have
happened with or without any degree of influence from RedHat. The fact
that it was actually implemented by the sysvinit maintainers should be a
big hint that we saw a good deal of value in it which would greatly
improve the flexibility and maintainability of the initscripts for the
benefit of our users. And also, without it, there would have been /even
more/ pressure to adopt systemd, since it removed the arguments about
sysvinit/initscripts being unable to handle a number of scenarios which
it previously couldn't cope with.


Regards,
Roger