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 [email protected] http://www.aurel32.net
