Re: usrmerge in bookworm
Hi Sven, On Sat, Oct 07, 2023 at 09:09:27AM +0200, Sven Joachim wrote: > On 2023-10-06 22:32 +, Andy Smith wrote: > > It got done years ago in Ubuntu, and their dpkg doesn't have this > > issue, as they've carried patches for that for all those years. > > Ubuntu may have patched out the dpkg complaints about usrmerge, but they > have _not_ added proper support for it. For instance, the problem > mentioned by the OP is present in Ubuntu's dpkg. I'm sorry, I was not aware of that and I stand corrected. Thanks! Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: usrmerge in bookworm
On 2023-10-06 22:32 +, Andy Smith wrote: > On Fri, Oct 06, 2023 at 04:42:56PM +0200, Urs Thuermann wrote: >> Greg Wooledge writes: >> >> > Yeah, usrmerge is a bit wonky in these early stages. >> >> $ apt-get changelog usrmerge | tail -n2 >> -- Marco d'Itri Tue, 04 Nov 2014 22:42:44 +0100 >> Fetched 11.0 kB in 0s (58.9 kB/s) >> >> Not what I'd call 'early' stages. > > It is for Debian, when the maintainer of dpkg is strongly opposed > to, and refuses to co-operate with, anything related to usrmerge. > > It got done years ago in Ubuntu, and their dpkg doesn't have this > issue, as they've carried patches for that for all those years. Ubuntu may have patched out the dpkg complaints about usrmerge, but they have _not_ added proper support for it. For instance, the problem mentioned by the OP is present in Ubuntu's dpkg. Cheers, Sven
Re: usrmerge in bookworm
Hello, On Fri, Oct 06, 2023 at 04:42:56PM +0200, Urs Thuermann wrote: > Greg Wooledge writes: > > > Yeah, usrmerge is a bit wonky in these early stages. > > $ apt-get changelog usrmerge | tail -n2 > -- Marco d'Itri Tue, 04 Nov 2014 22:42:44 +0100 > Fetched 11.0 kB in 0s (58.9 kB/s) > > Not what I'd call 'early' stages. It is for Debian, when the maintainer of dpkg is strongly opposed to, and refuses to co-operate with, anything related to usrmerge. It got done years ago in Ubuntu, and their dpkg doesn't have this issue, as they've carried patches for that for all those years. Though Debian has a much more diverse set of packages and user base and real issues HAVE been found in usrmerge so it's not a no-brainer, it's just that we would have gone through it and out the other side by now. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: usrmerge in bookworm
Greg Wooledge writes: > Yeah, usrmerge is a bit wonky in these early stages. $ apt-get changelog usrmerge | tail -n2 -- Marco d'Itri Tue, 04 Nov 2014 22:42:44 +0100 Fetched 11.0 kB in 0s (58.9 kB/s) Not what I'd call 'early' stages. > Part of the reason for this is that it's not *mandatory*, not > really. That seems to have changed in Debian 12: $ aptitude show init-system-helpers | egrep ^Prio\|^Dep Priority: required Depends: usrmerge | usr-is-merged In Debian 11, init-system-helpers did not depend on usrmerge. > There are still Debian systems -- important ones, which run the > internal infrastructure of Debian itself -- that aren't using it. Are those running older versions of Debian than stable? urs
Re: usrmerge in bookworm
Marco writes: > Am 06.10.2023 schrieb Steve Keller : > > > I have always been sceptical about /usr merge, since all binaries now > > appear in two places, "type sh" in bash gives the strange looking > > /usr/bin/sh where all Uni*ers are strongly used to /bin/sh. But also > > things like the following don't work anymore: > > Historic reasons, they don't exist anymore on current systems. > > > $ dpkg -S $(type -p sh) > > dpkg-query: no path found matching pattern /usr/bin/sh > > That is because /bin is now a symlink to /usr/bin and the file isn't > provided in /usr/bin by the package. I assume Steve (seemingly multi Un*x user) is aware about the historic reasons and how and why /usr-merge is implemented using symlinks. > > And I don't see a comfortable way around this. > > One way would be to strip off /usr from the string to search. That, of course, doesn't really help $ type -Pa ls /usr/bin/ls /bin/ls $ dpkg -S $(PATH=/bin type -Pa ls) coreutils: /bin/ls $ type -Pa gcc /usr/bin/gcc /bin/gcc $ dpkg -S $(PATH=/bin type -Pa gcc) dpkg-query: no path found matching pattern /bin/gcc because some packages have their binaries in /bin and others in /usr/bin, and likewise with /sbin vs. /usr/sbin, and /lib vs. /usr/lib. But the -a option to bash's 'type' builtin command helps: $ dpkg -S $(type -Pa ls gcc) dpkg-query: no path found matching pattern /usr/bin/ls coreutils: /bin/ls gcc: /usr/bin/gcc dpkg-query: no path found matching pattern /bin/gcc urs
Re: usrmerge in bookworm
On Fri, Oct 06, 2023 at 11:06:56AM +0200, Steve Keller wrote: > $ dpkg -S $(type -p sh) > dpkg-query: no path found matching pattern /usr/bin/sh > > And I don't see a comfortable way around this. Yeah, usrmerge is a bit wonky in these early stages. Part of the reason for this is that it's not *mandatory*, not really. There are still Debian systems -- important ones, which run the internal infrastructure of Debian itself -- that aren't using it. So, in order to continue to accomodate the non-merged systems, packages that provide certain well-known legacy pathnames like /bin/ls must continue to do so. They can't move to providing /usr/bin/ls because that may break things on non-merged systems. Corner cases like the one you showed are going to remain in place for many years.
Re: usrmerge in bookworm
Am 06.10.2023 schrieb Steve Keller : > I have upgraded from bullseye to bookworm and it seems the package > usrmerge is installed forcedly now. At least it has been installed > and I haven't been asked about it :-( > > I have always been sceptical about /usr merge, since all binaries now > appear in two places, "type sh" in bash gives the strange looking > /usr/bin/sh where all Uni*ers are strongly used to /bin/sh. But also > things like the following don't work anymore: Historic reasons, they don't exist anymore on current systems. > $ dpkg -S $(type -p sh) > dpkg-query: no path found matching pattern /usr/bin/sh That is because /bin is now a symlink to /usr/bin and the file isn't provided in /usr/bin by the package. > And I don't see a comfortable way around this. One way would be to strip off /usr from the string to search.
usrmerge in bookworm
I have upgraded from bullseye to bookworm and it seems the package usrmerge is installed forcedly now. At least it has been installed and I haven't been asked about it :-( I have always been sceptical about /usr merge, since all binaries now appear in two places, "type sh" in bash gives the strange looking /usr/bin/sh where all Uni*ers are strongly used to /bin/sh. But also things like the following don't work anymore: $ dpkg -S $(type -p sh) dpkg-query: no path found matching pattern /usr/bin/sh And I don't see a comfortable way around this. Steve
