Your message dated Thu, 7 Mar 2024 03:34:08 +0100
with message-id <zeknojdxe0vos...@thunder.hadrons.org>
and subject line Re: Bug#1065429: dpkg -s: spurious error "dpkg-query: error:
--status needs a valid package name"
has caused the Debian Bug report #1065429,
regarding dpkg -s: spurious error "dpkg-query: error: --status needs a valid
package name"
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.)
--
1065429: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065429
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.22.5
Severity: important
I get the following error:
cventin:~> dpkg -s libc6-dev
dpkg-query: error: --status needs a valid package name but 'libc6-dev' is not:
ambiguous package name 'libc6-dev' with more than one installed instance
while this is a valid package name: with an "apt" command, I get:
The following packages were automatically installed and are no longer required:
libnsl-dev libnsl-dev:i386 libnsl2:i386 libtirpc-dev libtirpc-dev:i386
^^^^^^^^^^
libtirpc3:i386
[...]
The package name is listed above.
"apt-cache show libc6-dev" also lists this package.
-- Package-specific info:
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dpkg depends on:
ii libbz2-1.0 1.0.8-5+b2
ii libc6 2.37-15
ii liblzma5 5.6.0-0.2
ii libmd0 1.1.0-2
ii libselinux1 3.5-2
ii libzstd1 1.5.5+dfsg2-2
ii tar 1.35+dfsg-3
ii zlib1g 1:1.3.dfsg-3+b1
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 2.7.12
pn debsig-verify <none>
-- no debconf information
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- End Message ---
--- Begin Message ---
Hi!
On Mon, 2024-03-04 at 13:47:00 +0100, Vincent Lefevre wrote:
> Package: dpkg
> Version: 1.22.5
> Severity: important
> I get the following error:
>
> cventin:~> dpkg -s libc6-dev
> dpkg-query: error: --status needs a valid package name but 'libc6-dev' is
> not: ambiguous package name 'libc6-dev' with more than one installed instance
>
> while this is a valid package name: with an "apt" command, I get:
>
> The following packages were automatically installed and are no longer
> required:
> libnsl-dev libnsl-dev:i386 libnsl2:i386 libtirpc-dev libtirpc-dev:i386
> ^^^^^^^^^^
> libtirpc3:i386
> [...]
>
> The package name is listed above.
I don't see a bug here. This has behaved this way since multiarch was
implemented, so that for Multi-Arch packages with multiple instances
installed would get reproducible data even when dpkg itself had been
cross-graded (which would change its native architecture). Ideally
when confronted with multiple instances, all of them would be printed
but callers could break as not expecting multiple paragraphs in those
cases. So you need to arch-qualify these packages, such as:
dpkg -s libc6-dev:amd64
> "apt-cache show libc6-dev" also lists this package.
apt behaves differently, this has been also a known discrepancy, but
then they operate in general differently when it comes to their CLI
arguments anyway.
As mentioned above, because I don't see a bug here, I'm closing this
report.
Thanks,
Guillem
--- End Message ---
