Your message dated Wed, 15 Dec 2021 13:05:45 +0100
with message-id <ybnagunvu1tml...@thunder.hadrons.org>
and subject line Re: Bug#1000715: dpkg -S fails to identify package for
coreutils files: says 'no path found matching pattern' instead
has caused the Debian Bug report #1000715,
regarding dpkg -S fails to identify package for coreutils files: says 'no path
found matching pattern' instead
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1000715: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000715
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.20.9
Distribution: Bookworm
Architecture: AMD64
Relevant because this could have something to do with which utilities
are statically linked to bash or exactly which coreutils we're talking
about:
bash is version 5.1-3.1 and coreutils is version 8.32-4.1
At the command line I type:
>dpkg -S /usr/bin/cp
I expect it to tell me
coreutils: /usr/bin/cp
instead, it falsely reports
dpkg-query: no path found matching pattern /usr/bin/cp
So I check some other things and find it working correctly.
>dpkg -S /usr/bin/dpkg
dpkg: /usr/bin/dpkg
>dpkg -S /usr/bin/xz
xz-utils: /usr/bin/xz
>dpkg -S /usr/bin/yelp
yelp: /usr/bin/yelp
In fact it responds correctly to everything I've tried EXCEPT files
installed by coreutils:
>dpkg -S /usr/bin/cp
dpkg-query: no path found matching pattern /usr/bin/cp
>dpkg -S /usr/bin/ls
dpkg-query: no path found matching pattern /usr/bin/ls
>dpkg -S /usr/bin/rmdir
dpkg-query: no path found matching pattern /usr/bin/rmdir
>dpkg -S /usr/bin/mv
dpkg-query: no path found matching pattern /usr/bin/mv
>dpkg -S /usr/bin/grep
dpkg-query: no path found matching pattern /usr/bin/grep
But it's not entirely consistent. There are some coreutils files it
identifies correctly:
>dpkg -S /usr/bin/yes
coreutils: /usr/bin/yes
I don't know why this is happening. But I thought I should report it.
Bear
--- End Message ---
--- Begin Message ---
Hi!
On Wed, 2021-12-15 at 03:57:06 +0100, Guillem Jover wrote:
> On Sun, 2021-11-28 at 19:09:37 +0000, Ray Dillinger wrote:
> > I suppose this means I don't actually understand how dpkg works at all.
> > The files are there in /usr/bin, and SOMETHING, presumably an installer
> > run by dpkg the most recent time coreutils was updated, installed them.
> > But dpkg does not know which installer was running at the time? Does it
> > rely on some information separate from keeping track of the actual files
> > written while an installer is running, to know which installer was
> > responsible for writing the files? That's very unexpected at least to
> > me. It seems like manually maintaining the lists would be a lot more
> > work than coding the automatic tracking I had assumed was happening.
> > I'd be interested in understanding the design constraints that make it
> > preferable.
>
> This is due to some people in Debian having pushed to have systems be
> installed with the broken and unsupported merged-usr-via-aliased-symlinks,
> while dpkg has never supported that.
>
> <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>
>
> > Not that it makes much difference on the ground right now. The news
> > relevant to this is, it's on your radar already as an issue with this
> > migration/merge situation, and I'm not bringing up anything that
> > wouldn't eventually get fixed otherwise. So I suppose all there is to
> > say is "known issue" and "workaround available" and close this when you
> > get to it in the due course of the migration work. I hope various
> > aspects of this don't cause you too many more headaches.
>
> Well, personally I think the approach is broken, and adding support
> for this in dpkg properly would conflict with other features that are
> in the pipeline, and even then would not even be feasible for several
> Debian release cycles anyway. And then the layout would still be
> problematic non the less.
>
> > Honestly I don't have much opinion on the /bin and /usr/bin merger; the
> > pros and cons seem balanced on a knife edge to me. It seems like an
> > objectively good impulse to reduce complexity, but it also seems like a
> > hell of a lot of work, pain, and confusion to go through right now for
> > what will be, in any particular future year, only a very minor benefit.
> > On the third hand there won't come a time in the future when it's easier
> > or less painful than right now, so the choice is existential; rather
> > than "when", we face "whether at all" because the pro and con arguments
> > are unlikely to change.
>
> My recommendation is to either reinstall with a non-broken layout, or
> revert the switch by running something like dpkg's dpkg-fsys-usrunmess
> from testing, after reading its man page, as mentioned in the FAQ entry.
And not to mention, that this is not even supportable nor otherwise
fixable right now from dpkg's side due to the messy hack that goes
behind dpkg's back. This is tracked (and has been known and ignored
for years) as #848622, so closing this one.
Thanks,
Guillem
--- End Message ---
