Re: Bug#747261: apt: Please add support for cross-architecture conflicts
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.
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.
Thanks,
Guillem
Reply to: