apt-mark prints ambiguous package name

[Jarno Suni]

Example in shell:

$ dpkg-query -W -f='${binary:Package} ${Status}\n' libfontconfig1
libfontconfig1:amd64 install ok installed
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:amd64
$ apt-mark showmanual libfontconfig1
libfontconfig1 <---- should be libfontconfig1:amd64
$ apt-mark showmanual libfontconfig1:amd64
libfontconfig1 <---- should be libfontconfig1:amd64

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: apt 1.0.1ubuntu2.13
ProcVersionSignature: Ubuntu 3.13.0-85.129-lowlatency 3.13.11-ckt36
Uname: Linux 3.13.0-85-lowlatency x86_64
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.conffile..etc.kernel.postinst.d.apt.auto.removal: [modified]
mtime.conffile..etc.kernel.postinst.d.apt.auto.removal: 2016-02-03T01:46:24.317010

[David Kalnischkies (donkult)]

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…

[Jarno Suni (jarnos)]

The architecture of e.g. debconf is not some specific architecture, but "all".

So when you want to use the output of apt-mark as an argument for dpkg(-query), you need to tune the name by a shell function like this, right? :

dpkg-pkgname() {
 nativearch=$([ "$(uname -i)" = "x86_64" ] && echo amd64 || echo i386)
 [ -f /var/lib/dpkg/info/"$1".list ] && echo $1 || echo $1:amd64
}

[Jarno Suni (jarnos)]

Correction, the last amd64 should be replaced by "$nativearch".

[David Kalnischkies (donkult)]

I presume that works (I would be using nativearch="$(dpkg --print-architecture)" through – and poking directly into info/ is discouraged. Checking exitcode of commands like 'dpkg-query -s "$1"' might be better), but note that with a "foo:all" you aren't talking about a package as packages can't have this special architecture. It is a specific version of a package "foo:native" which was built such that it works independently of the underlying native architecture – so the display of fully arch-qualified package names would still be "wrong" as apt-mark talks about packages, not about versions.

This distinction comes into play e.g. if the source package changes from any to all (or vice versa) as this resembles a 'normal' upgrade (which carries over data like the autobit), while there is no upgrade path in the crossgrading foo:i386 to foo:amd64 case.

[Jarno Suni (jarnos)]

$ dpkg-query -s "libfontconfig1"
prints the status of the amd64 package, but
$ dpkg-query -W -f='${binary:Package}\n' "libfontconfig1"
prints the package name with both amd64 and i386 architectures.