[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#747261: apt: Please add support for cross-architecture conflicts



On Mon, May 19, 2014 at 07:17:22AM +0200, Johannes Schauer wrote:
> 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.

Indeed, it seems that dose3 ignore the arch qualifier. Just realized
that, as dose3 is used by wanna-build to determine if a package is
buildable or not, and it currently breaks for some architectures. For
example:

| gcc-4.8 build-depends on:
| - libc6-dev-s390
| libc6-dev-s390 depends on:
| - libc6-s390 (= 2.18-6)
| gcc-4.8 build-depends on:
| - libc6-dev (>= 2.13-5)
| libc6-dev depends on:
| - libc6 (= 2.18-6)
| libc6-s390 conflicts with:
| - libc6

> 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?

I think before changing dose3, apt or dpkg, we need to agree on a
solution. For now I am going to revert the changes done on the libc
side, but it means that the bug is current not fixable.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: