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

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

Scott James Remnant <scott@netsplit.com> writes:

> 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

ABI: strict or ia32/amd64/... is all the same. dpkg or dpkg-gencontrol
can figure out what to put behind "ABI:" if a template is present in
the control file. The presence of such a line alone is enough, the
actual value is not (yet) important. Only for mips, which has 3 ABIs
for 2 archs, the actual value might be important.

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

Irelevant to the problem of renaming or not renaming debs. The common
files must be split out into a bianry-all package or some "silently
overwrite" rule must be devised. I only see silently overwriting (or
rather renaming and linking one of them) as an option for the
copyright and changelog file. Basically for the doc directory.
Anything else realy should be split.

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

No they can't. /usr/share is shareable across all architectures. So
certainly its shareable between i386 and amd64. Anything else is a
violation of policy.
 
> 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.

/usr/lib/package/... is a problem. But for amd64 that should be
/usr/lib64/package since lib_prefix defaults to $prefix/lib64 for the
architecture.

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

lib_prefix in autoconf takes care of many of those.

> 	*/bin/* -> */bin64/*
> 	*/sbin/* -> */sbin64/*
> 	*/games/* -> */games64/*

Only lib packages are suposed to have two abis installed at the same
time. Files in bin and bin64 should allways be disjunct so splitting
them is not neccessary. Same for sbin and games.

Any examples why you would need the split?

> 	/opt/* -> /opt64/*
> 		(library packages are allowed to contain binaries)

Not debians problem :)

> 	/etc/* -> /etc64/*
> 		(config files may be architecture specific)

Hardly irregular for libs to have conffig files. Any example?

> 	*/include/* -> */include64/*
> 		(header files may be architecture specific)

Use #ifdef __AMD64__ #elif __I386__ ....

> 	/usr/share/doc/<pkg> -> /usr/share/doc/<pkg>64
> 		(and anything else policy specifies)

Automatically renamed and one linked in case of conflicts by dpkg.

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

.pc? You mean .pic?

Thats also true when renaming and not renaming packages. The lib /
lib64 split should take care of any problems there.

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

Contents of packages and name of packages are two seperate
problems. We are aware of the further problems with the contents and
splitting out common files into binary-all packages even more
aggresively than its already done seems to be the only way to go for
the contents.

MfG
        Goswin