Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Anthony DeRobertis <asd@suespammers.org> writes:

> On Jan 11, 2004, at 17:54, Scott James Remnant wrote:
> 
> > Then I don't understand how you're going to deal with this:
> >
> > binpkg depends on libpkg.
> >
> > 1) Provide both binpkg:i386 and binpkg:amd64, each depending on the
> >    library with the correct ABI.
> 
> That's how I understand it. binpkg:i386 is currently provided in our
> i386 port, and binpkg:amd64 will be provided by the amd64 port.
> 
> 
> > Except unless you use bin64, these
> >    will not be dual-installable
> 
> Correct.
> 
> > meaning that only one of the libraries
> >    will ever need to be installed at the same time as well.
> 
> Does not follow. I can have binpkg:i386 and binpkg2:amd64 both
> installed, and they can both depend on libpkg.
> 
> 
> A library is rather silly if it's only used by --- and will only ever
> by used by --- one program (hasn't stopped people, I know).
> 
> 
> BTW: How are we going to handle that some dependencies are
> architecture-dependent, like libraries, while others aren't?

There are two things here: Dependency on the existance and dependency
on the ABI of a library.

The two ways (renaming debs or not) differ in the way they handle
this:

1. renaming libc6.deb to lib64c6.deb

64 bit packages (just for the multiarch 64bit, not alpha or ia64) must
depend on lib64c6.deb. The sources must depend on lib64c6-dev.
lib64c6-dev is a bad example because its build-essential but ignore
that for now.

That means pretty much every sources (every source thats compiled for
multiarch) control file has to be changed.  Failure to change the depends
often results in a broken deb that works most of the time (other
working debs pull in the right depends by chance)

2. not renaming libc6.deb

Packages depend on libc6 and sources on libc6-dev and libc6/libc6-dev
have a "ABI: ia32" or "Abi: amd64" line in their control file.

When resolving depends apt/dpkg will look for libc6/libc6-dev. When
they find an available version they check for the "ABI: ..." line. If
there is none (like in make) the depends is matches as before. If a
line is found apt/dpkg check if the ABI provided is compatible with
the architecture of the package needing it (ABI: ia32 is compatible to
i386, i486, i586, i686 and ABI: amd64 is compatible to amd64).

That means apt/dpkg has to be changed and then all libraries that
get ported to 64bit. The autobuilder foramd64 can easily check for
files in /lib, /lib64, /usr/lib and /usr/lib64 and verify that an ABI
line is set correctly.

The package providing the abi knows best that is does so. Its easier
to change that one lib than every package depending on it.

> Come to think of it, a perl script's dependencies...
> 
> > Once you take into account the various inter-library dependencies where
> > this is an issue, you'll find you pretty well almost need an all-i386
> > bin or all-amd64 bin anyway.
> 
> Not at all. Most packages have no dependencies on each other. If our
> dependencies were really the tangled web you suggest, I doubt anything
> would propogate into testing, ever. Even with the RM's help.
> 
> 
> > Are you planning on submitting your change to the FHS that
> > configuration
> 
> > files are now required to be architecture independent?  Because that's
> > certainly exactly the opposite of what the FHS says.
> 
> More importantly, sharing configuration files between packages makes
> for GREAT fun on --purge.

Don't tell me. :)

In my opinion its easier to force shared configuration files out into
a -common package than to patch things at the dpkg level. As much as I
hate to create tiny debs just for that its the easiest.

MfG
        Goswin