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