[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 Sun, 2004-01-11 at 18:15, Goswin von Brederlow wrote:

> Anthony Towns <aj@azure.humbug.org.au> writes:
> > This proposal means you can't look at Packages files alone to work out
> > the meaning of dependencies, in the above you have to also know that
> > "i686" is a subarch, and "amd64" is distinct from "i386", but compatible.
> Yes. But thats pretty much the only way you can merge
> binary-i386/i486/i586/i686/amd64 all into one system.
Why not use the ABI line for this?

ABI: ia32
ABI: amd64
ABI: sparc32
ABI: sparc64

The presence of an ABI indicates a strict need, the value specifies what
set of packages that need is based on.

> > package, one name" rule is really bad. What does "dpkg -L libc6" do on
> The thing is you still have one package, one name. You just have
> multiple debs providing different ABIs of the same package. I can just
> as well say that renaming libc6 to lib64c6 breaks the one package, one
> name rule. One package (libc6) now has two names (libc6 and lib64c6).
libc6 includes much more than just /lib/* though, what do you do with
all the other files?  How are you going to handle the conflict between
/usr/share/zoneinfo from libc6:i386 and the same from libc6:ia64?

You can't make the assumption those files are identical, they could (for
example) be affected by the different word size[0].  libc6:i386 might
only be able to read the 32-bit /usr/share/zoneinfo, and libc6:amd64
might only be able to read the 64-bit /usr/share/zoneinfo.

For these packages, you've already got to very carefully move things and
compile them differently to look for their data in different places --
they're now no longer identical packages, so probably should have
different names and different bug tracking.

> The linking is only needed when alowing different versions of the same
> package with different ABIs to be installed. Otherwise, with the same
> version, the files in /usr/share should always be identical or at
> least exchangable and could be silently overwritten. I prever linking.
Things you're going to have to move:

	*/lib/* -> */lib64/*
		(lib doesn't just contain .so files)
	*/bin/* -> */bin64/*
	*/sbin/* -> */sbin64/*
	*/games/* -> */games64/*
	/opt/* -> /opt64/*
		(library packages are allowed to contain binaries)
	/etc/* -> /etc64/*
		(config files may be architecture specific)
	*/include/* -> */include64/*
		(header files may be architecture specific)
	/usr/share/doc/<pkg> -> /usr/share/doc/<pkg>64
		(and anything else policy specifies)

You're also going to have to ship different .la files, different .pc
files and anything else build-magic.

You won't be able to handle all this inside dpkg with magic, the
packages will have to be manually tailored to not conflict with their
32-bit counterpart (omitting shared /share is probably the easiest) --
at which point they become totally different packages anyway!


[0] Whether this is true for these files or not is irrelevant, it's
    going to be true for *something*.  I've just picked the first
    example library and path that came to mind.
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: