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

Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages



On Tue, Jun 03, 2014 at 01:21:13PM +0200, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2014-05-19 at 15:56:14 +0200, Aurelien Jarno wrote:
> > On Mon, May 19, 2014 at 02:01:15PM +0200, Jakub Wilk wrote:
> > > * Aurelien Jarno <aurelien@aurel32.net>, 2014-05-19, 13:28:
> > > > So following your way, it would be exactly the same for libc6:sparc.
> > > >
> > > > libc6-i386 also provides /lib/ld-linux.so.2. It should be
> > > > co-installable with libc6:i386, but libc6:sparc should not be
> > > > co-installable with libc6:i386 or libc6-i386.
> > > 
> > > Oh, right. Couldn't the biarch packages die already? :)
> > 
> > Unfortunately, as long as we keep GCC, we will need them, even if they
> > are a pain.
> 
> Actually, why? I guess I might be missing something obvious, but even
> if GCC wants to preserve the bi/triarch stuff (which I think is a bad
> idea), why does glibc need to keep them in the current form as well?

GCC needs to the libc packages to build the bi/triarch support.

> Couldn't they be switched to empty packages depending on the actual
> packages from the other arch, using either cross-arch dependencies or
> the arch-annotated provides or similar? Or alternatively be switched
> to native packages, or be simply provided by the native package,
> similar to how the ia32-libs stuff got transitioned?

There are multiple problems with that:
- Currently gcc does not look in the multiarch path for the multilib
  case. This can probably be fixed though.
- Cross-architecture dependencies are not supported by the build
  infrastructure.
- We don't always have the equivalent bi/triarch architecture in debian.
  We basically have it for i386/amd64, but we don't have it for
  mipsn32, mipsn32el, mips64, mips64el, s390, ppc64, sparc64. There were
  some discussion about having a minimal set of packages for these
  architectures a few years ago, but it requires a lot of changes in the
  infrastructure and also at the packaging level.

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


Reply to: