On Sun, 2004-01-11 at 18:15, Goswin von Brederlow wrote: > Anthony Towns <email@example.com> 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. 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! Scott  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?
Description: This is a digitally signed message part