apt-mark prints ambiguous package name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt (Ubuntu) |
Opinion
|
Undecided
|
Unassigned |
Bug Description
Example in shell:
$ dpkg-query -W -f='${binary:
libfontconfig1:
libfontconfig1:i386 install ok installed
$ apt-mark showauto libfontconfig1
$ apt-mark showauto libfontconfig1:i386
libfontconfig1:i386
$ apt-mark showmanual libfontconfig1:i386
$ apt-mark showauto libfontconfig1:
$ apt-mark showmanual libfontconfig1
libfontconfig1 <---- should be libfontconfig1:
$ apt-mark showmanual libfontconfig1:
libfontconfig1 <---- should be libfontconfig1:
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: apt 1.0.1ubuntu2.13
ProcVersionSign
Uname: Linux 3.13.0-
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
CurrentDesktop: XFCE
Date: Sat Apr 30 12:50:48 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-09-21 (587 days ago)
InstallationMedia: Ubuntu-Studio 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.1)
SourcePackage: apt
UpgradeStatus: No upgrade log present (probably fresh install)
modified.
mtime.conffile.
The names aren't ambiguous – if apt prints no architecture it is ALWAYS the native architecture. This is this way for compatibility reasons as apt hadn't previously printed any architecture – because they were all native – so old tools, scripts, processes, … sticking to the common case of single-architecture systems do not need to be touched/fixed.
It just happens to be a different convention than dpkg is using – which prints the architecture only if it could be ambiguous, like for all packages marked as M-A:same (Since recently it also shows the architecture for M-A:foreign packages of a non-native architecture, too) and in exchange requires an architecture to be given (for M-A:same) even if it isn't ambiguous [which broke pre-multiarch tools, but most tools interacting with dpkg do this via apt which shielded them].
APT can't operate with this convention as basically every package is available in all architectures, so a package name is always ambiguous and hence all package names would need to be fully arch-qualified all the time. That would be a lot of noise…