Bug#820826: libc6-dev-amd64: Multiarch allows conflicting packages, and apt-get does not detect this
On 2016-04-12 21:04, Sean wrote:
> Package: libc6-dev-amd64
> Version: 2.19-18+deb8u4
> Severity: normal
>
> Dear Maintainer,
>
> I'm not an expert in the cross-compilation toolchain or its Debian repository configuration, but the libc6-dev-* packages appear to be set up with architecture qualifiers so that only one will ever be installed; since they conflict.
> Multiarch support allows multiple of these packages to be attempted to be installed.
>
> 1. The wrong package for the architecture is allowed to be installed through multiarch with no complaints (and possibly as a dependency of, eg, a misconfigured other package)
> 2. If apt-get is requested to install another, conflicting, package in this family, it will attempt to do so until dpkg discovers the conflict and the operation fails with no error message explaining why
> 1+2. Synergistically, this can allow the wrong package to get onto a system with no complaints, then when the legitimate package is required by something, apt-get cannot install it though it attempts to, giving a dpkg error message that doesn't explain the underlying problem (and apt-get suggests apt-get -f install, which does nothing to fix it of course)
This has already been reported multiple time, for example in #702962.
Anyway apt-get simply do not support cross-architecture conflict, so
there is nothing that can be done on the libc side.
> + Also, the package naming scheme may be confusing to intermediate and novice users if they're expected to find that a package is incorrectly installed and which one, as libc6-dev-amd64 is *not* to be installed on amd64 systems, and similarly for libc6-dev-i386 and i386 systems; their qualifiers are setup to only be allowed on the opposite architecture (unless multiarch is enabled, which entirely leads to this situation)
>
> + I presume this would apply to other architectures as well, and possibly other packages (esp. cross-compilation related ones?), but these were the packages I personally encountered in this event.
I don't see how do you want to call the amd64 libc without using the
amd64 name in it. These names have been there for almost 10 years, so
I don't think they are problematic.
I am therefore closing this bug.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: