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

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



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.

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

> 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".

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

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

               Linux.conf.au 2004 -- Because we can.
           http://conf.linux.org.au/ -- Jan 12-17, 2004

Attachment: signature.asc
Description: Digital signature


Reply to: