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

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

Anthony Towns <aj@azure.humbug.org.au> writes:

> On Tue, Jan 13, 2004 at 09:41:52AM +0100, Goswin von Brederlow wrote:
> > There are two things here: Dependency on the existance and dependency
> > on the ABI of a library.
> 
> I'd break that up differently. Packages that are depended upon offer an
> API.  lib packages offer an API that isn't compatible across architectures
> (the .so file). Binary packages offer an API that normally is compatible
> across architectures -- sed works the same whether it's an i386 or amd64
> binary, so either package can be used to satisfy a "Depends: sed" clause.
> 
> > 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 is, each package-level API is represented by a particular package
> name.  It might be a virtual package name (mail-transport-agent), it
> might be an architecture independent name (sed), or it might only be
> available from a particular arch (libc6-amd64).
> 
> > That means pretty much every sources (every source thats compiled for
> > multiarch) control file has to be changed.  
> 
> It means every package that doesn't provide an arch-independent API has
> to either not be built on AMD64, or it has to have its source modified
> to have a different name on each arch.
> 
> Things like sed don't have to be touched, since their Depends: field is
> set automatically to libc6 / libc6.1 / libc6-amd64 / whatever based on
> the shlibdeps file for glibc.

sed is one of the minority that doesn't need changes:

Build-Depends: texinfo
and
Pre-Depends: ${shlibs:Pre-Depends}

But over 50% of all source packages have a *-dev package in its
build-depends or depend on a library. Add the source packages that
have a versioned depends on a library in its control file.

One can grep around for the obvious cases and hope the rest fill sort
itself out over time but too many packages are affected just by
renaming the libs and -dev packages.


If the "make *-dev Architecture: all" proposal is found reasonable a
lot of work would be avoided. Grepping around a bit in the Sources
file and sources control file it looks like there are:

~200 packages with Build-Depends on lib* (-> lib64* with renaming)
~600 (very rough) packages with Depends on lib* (no shlibs magic)

That's way less to worry about already.

> > 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)
> 
> It means we have to fix the entire distro to support AMD64 at a reasonable
> level. With decent devel tool support (to make it easy to build a package
> that's called libfoo on i386, but libfoo-amd64 on AMD64), this should
> not be terribly difficult.

Failure of one package to do so (which is a major issue when starting)
will cause every i386 binary that depends on the lib to be broken when
said lib is installed by apt-get upgrade.

Renaming is not a very secure porting path since its hard to catch
misbuilds. Not everything is called libfoo / lib64foo (xlibs and
zlib1g just to name 2).

Renaming is also ugly the way its currently handled with special hacks
to several build tools and extra entries in the control file (like
'Package.64: lib64foo').

> > 2. not renaming libc6.deb
> 
> Which is to say "adding an extra control field (beyond Package: and
> Version:) that has an effect on dependency resolution".

yes.

The flag would control dual instability and can easily be verified
against files in */lib/ and */lib64/ dirs by the autobuilder.
Misbuilds can be detected.

The flag acts like a implicit ":<abi>" added to the depends.

> > 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.
> 
> Libraries probably shouldn't be providing binaries or configuration
> files anyway. I'm half inclined to consider that requirement a feature,
> not a bug.

Hear, hear. :)

> Cheers,
> aj

MfG
        Goswin