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

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

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

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

> > 	/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
my system from a quick grep) include libnss-db, libpam-modules, libao2
and libruby1.8.

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

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

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

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

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: