Bug#747261: apt: Please add support for cross-architecture conflicts
Hi all,
Quoting Guillem Jover (2014-05-19 00:06:52)
> 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
> > […]
thank you Aurelien, for this super test case! :)
> 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.
Coming from the dose3 side of things, I'd like to ignore the "real problem"
mentioned by Guillem for a bit to ask for your opinion about the right thing to
do when encountering arch-qualified self-conflicts of a multiarch same package
from a resolver perspective.
Currently, dose3 has no problem co-installing libc6:mips and libc6:powerpc and
I guess this is in most part because we tested our crossbuild dependency
resolution against apt behaviour and because we never thought of this specific
situation happening.
Should resolvers or dependency checkers like dpkg, apt and dose3 continue to
ignore the architecture qualification for self-conflicts of m-a:same packages?
While it is certainly "weird" that a m-a:same package would not be
co-installable for a certain architecture combination, I guess somebody
encoding this conflict would expect that this would work nevertheless.
What do you think?
cheers, josch
Reply to: