Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

usrmerge in bookworm

25 views
Skip to first unread message

Steve Keller

unread,
Oct 6, 2023, 5:30:06 AM10/6/23
to
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

Marco

unread,
Oct 6, 2023, 5:50:06 AM10/6/23
to
Am 06.10.2023 schrieb Steve Keller <keller...@gmx.de>:

> 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.

Greg Wooledge

unread,
Oct 6, 2023, 7:20:06 AM10/6/23
to
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.

Urs Thuermann

unread,
Oct 6, 2023, 9:50:06 AM10/6/23
to
Marco <m...@dorfdsl.de> writes:

> Am 06.10.2023 schrieb Steve Keller <keller...@gmx.de>:
>
> > 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

Urs Thuermann

unread,
Oct 6, 2023, 10:50:06 AM10/6/23
to
Greg Wooledge <gr...@wooledge.org> writes:

> Yeah, usrmerge is a bit wonky in these early stages.

$ apt-get changelog usrmerge | tail -n2
-- Marco d'Itri <m...@linux.it> 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

Andy Smith

unread,
Oct 6, 2023, 6:40:06 PM10/6/23
to
Hello,

On Fri, Oct 06, 2023 at 04:42:56PM +0200, Urs Thuermann wrote:
> Greg Wooledge <gr...@wooledge.org> writes:
>
> > Yeah, usrmerge is a bit wonky in these early stages.
>
> $ apt-get changelog usrmerge | tail -n2
> -- Marco d'Itri <m...@linux.it> 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

Sven Joachim

unread,
Oct 7, 2023, 3:10:05 AM10/7/23
to
On 2023-10-06 22:32 +0000, Andy Smith wrote:

> On Fri, Oct 06, 2023 at 04:42:56PM +0200, Urs Thuermann wrote:
>> Greg Wooledge <gr...@wooledge.org> writes:
>>
>> > Yeah, usrmerge is a bit wonky in these early stages.
>>
>> $ apt-get changelog usrmerge | tail -n2
>> -- Marco d'Itri <m...@linux.it> 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

Andy Smith

unread,
Oct 7, 2023, 4:30:06 PM10/7/23
to
Hi Sven,
I'm sorry, I was not aware of that and I stand corrected.

Thanks!
0 new messages