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 19:54, Goswin von Brederlow wrote:
> 
> > Scott James Remnant <scott@netsplit.com> writes:
> > 
> > > On Sun, 2004-01-11 at 18:15, Goswin von Brederlow wrote:
> > > 
> > > > 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.
> > 
> Why?  So you're stating that for your method to work you're going to
> need to fundamentally change many library packages?
> 
> > > 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.
> > 
> Nice to see you deliberately ignored this footnote:
> 
> > > [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.
> 
> It's so much easier to ignore the problem, isn't it? 
> 
> > > 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.
> > 
> So the packages are going to be built differently, probably need
> different postinst/prerm to cope with some things under $libdir,
> excellent work there keeping them identical :-)

No, I'm saying the splitting has to be done either way.

> > > > 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.
> > 
> The whole world does not use Autoconf...
> 
> How you planning to deal with /usr/X11R6/*, btw? :-)

/usr/X11R6/lib64. Again thats a problem with and without renaming.

> > > 	*/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.
> > 
> Sorry, where did you pick this "should" up from?  Don't go adding
> "should"s where "should" doesn't exist.  Neither policy nor practice
> suggest that you can't stick support binaries into a library package.

Mixing libraries and binaries into one package will break for
multiarch. Of cause that is a problem if anyone is doing it but
splitting binaries out into their own packages sounds better than to
split bin, sbin and games and doubling the PATH.

Just think of all the scripts that use /bin/bash, /bin/sh, .... All
those would break with /bin64/bash, /bin64/sh, .... I don't think
anyone will go for a bin / bin64 split.

> "Files in bin and bin64 should always be [separated] so splitting them
> is not necessary."
> 
> Do you know how little sense that makes? :-)
> 
> So we've now got a bin64, sbin64 and games64 ... merry hell that's going
> to play with people's $PATH :-)  A library is well within its rights to
> require a support binary that needs the same ABI as the library,
> remember.  That support binary might even be used by users, so belongs
> in bin or sbin.

Yes, that would be hell. Do we have any library that needs a support
binary that is in bin or sbin? /usr/lib/package/support-binary and
/usr/lib64/package/support-binary would be fine so far.

> > > 	/etc/* -> /etc64/*
> > > 		(config files may be architecture specific)
> > 
> > Hardly irregular for libs to have conffig files. Any example?
> > 
> libc6 springs immediately to mind, now you mention it.  Others (just on

libc6 coexists nicely with the li64c6 package. Whatever config files
it has in /etc can aparently be shared.

> my system from a quick grep) include libnss-db, libpam-modules, libao2
> and libruby1.8.

Where is the problem with those packages? Whats architecture dependent
on their config files?

> This doesn't include the 100 or so non lib* packages which contain .so
> files and files in /etc.

Just having the files means they have to be split into a common
package. Only if they are realy dependent on the architecture there is
a problem.

> > > 	*/include/* -> */include64/*
> > > 		(header files may be architecture specific)
> > 
> > Use #ifdef __AMD64__ #elif __I386__ ....
> > 
> There are situations where this isn't going to be possible, an entire
> library might only exist on one of these ABI platforms.

Then there is only one package supplying the headers and only for that
platform anything will depend on it (and live).

> > > You're also going to have to ship different .la files, different .pc
> > > files and anything else build-magic.
> > 
> > .pc? You mean .pic?
> > 
> No, I mean .pc
> 
> > Thats also true when renaming and not renaming packages. The lib /
> > lib64 split should take care of any problems there.
> > 
> Exactly, so by not renaming packages you actually haven't solved *ANY*
> problem but created a hell of a mess.

The question wether to rename or not concerns the amount and kind of
changes needed to each source package. Making dpkg match up library
and binary depends with different strictnes greatly reduces the
chnages needed in the control and rules file.

The need for /lib64/ for amd64 libraries is needed wether we rename or
not and is a seperate issue. Also any problems with file overlaps
apart from /var/lib/dpkg/info and /usr/share/doc/<pkg> are unrelated
to renaming and as such no argument for or against.

You could use it as an argument against multiarch support in general
and vote for a pure i386 and pure amd64 system only. But then where do
you get 3rd party i386 packages for amd64 from?

> > > 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.
> > 
> Or just have separately named packages?  With the "lesser ABI" package
> depending on the "major ABI" one as I outlined in my other e-mail.
> 
> Scott

Ok, the lesser abi is i386. Please do change sarge. :)

As said before there are 3 groups:

1. pure i386 system
2. pure amd64 system
3. multiarch system

SuSe and RH only support 1 and 2. Debian wanted to support all 3 and
hat conflicts with one ABIs packages depending on the other. Forcing
the i386 packages on pure amd64 users bloats the system needlessly.
You might not like it but so far the middle ground for all has been
to support all 3 setups even if that means eventually splitting a
bunch of packages to prevent the bloat.

MfG
        Goswin