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