Bug#747261: apt: Please add support for cross-architecture conflicts
Hi!
On Mon, May 19, 2014 at 12:06:52AM +0200, Guillem Jover wrote:
> Hi!
>
> On Fri, 2014-05-16 at 15:23:42 +0200, David Kalnischkies wrote:
> > On Fri, May 16, 2014 at 12:57:27AM +0200, Aurelien Jarno wrote:
> > > On Mon, May 12, 2014 at 09:03:50PM +0200, David Kalnischkies wrote:
> > > > On Tue, May 06, 2014 at 11:22:00PM +0200, Aurelien Jarno wrote:
> > > | # apt-cache show libc6:mips
> > […]
> > > | Conflicts: libc6:hppa, libc6:m68k, libc6:mipsel, libc6:powerpc, libc6:s390, prelink (<= 0.0.20090311-1), tzdata (<< 2007k-1), tzdata-etch
> > […]
> > > | # apt-cache show libc6:powerpc
> > […]
> > > | Conflicts: libc6:hppa, libc6:m68k, libc6:mips, libc6:mipsel, libc6:s390, prelink (<= 0.0.20090311-1), tzdata (<< 2007k-1), tzdata-etch
> > […]
> > >
> > > Of course it also shows that dpkg also do not support it, but having apt
> > > catching that case would already catches most of the problems.
>
> > Ahhhh, you are refering to "self"-conflicts…
>
> > The A == B case is indeed currently unsupported/ignored as they are
> > treated as 'normal' self-conflicts and are hence ignored as specified
> > by policy as §7.4 explicitly says:
> > | A special exception is made for packages which declare a conflict with
> > | their own package name, or with a virtual package which they provide
> > | (see below): this does not prevent their installation, and allows a
> > | package to conflict with others providing a replacement for it.
> >
> > Policy isn't all that talkative about M-A however, so that might just be
> > me reading way too much into an 'old' sentence of the policy, but I tend
> > to be nervous when it comes to breaking the policy…
>
> In principle I can see how it might make sense to allow arch-qualified
> self-Conflicts, because that's a pretty specific and direct request in
> the metadata. But then this would be an exception to the exception, and
> mainly and at least for now only for glibc (?), because in theory all
> M-A:same packages should be co-installable across all arches by design.
> Also it would possibly stop being coherent with how versioned
> self-Conflicts would work, once versioned Provides are implemented. It
> would also not work with stable tools.
>
> The real problem here, and the one I think would be ideal to get fixed
> even if only mid/long-term is that the ELF interpreter encoded in
> binaries uses the same path on different architectures, which kind of
> defeats the point of multiarch. Personally I think we should consider
> switching the ELF interpreter to the native multiarch paths, and just
> provide the legacy compat symlinks in a separate package, which for a
> transitional period (of indeterminated length) would get Pre-Depended
> by default. Although I realize those paths are considered part of the
> ABI (?), so it would eventually break compat with old binaries or
> binaries from other vendors, distros, etc, but there could always be
> the compat packages around.
The ELF interpreter is part of the ABI. Unfortunately we have to deal
with that and we basically can't change it. If we change it in the libc6
package, we have to also change it the ELF INTERP field in all the
binaries build by GCC, unless we always install the compat package.
Doing so means that any binary built on Debian will not work on other
distributions unless they provide reverse compat symlinks.
In short this mean changing the upstream ABI of most architectures in
Debian, not something realistic except maybe for the long long term.
> This could also be fixed as part of such hypothetical transition (or
> not), by moving such legacy linker symlinks to another package with an
> arch-specific package name, and then the arch-qualified Conflicts
> would work. I realize short-term this would look a bit dire, compared
> to just using arch-qualified self-Conflicts, though.
This looks really complicated, and dealing with the ELF interpreter
symlink move to another package usually means you take risk of breaking
systems. We already killed hundred of systems that way, and we still
haven't fixed all the corner cases. We should not try to break more
systems.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: