Fedora Core 3

[Paul Jakma]

On Mon, 19 Jul 2004, Thorsten Leemhuis wrote:

> Is it specified somewhere or is it you opinion?

My opinion, given that there is a huge body of existing RPMs out 
there for i386 and they're unlikely to be going away, and i'd like to 
be able to install them without fear of overwriting x86_64 binaries.

Shifting x86_64 to bin64 would be one line in .rpmmacros and an 
overnight rebuild of the x86_64 RPMS. RedHat almost certainly have 
the build system in place to do this overnight. Punting i386 RPMs to 
bin32 directories OTOH would be almost impossible. (paths in cpio 
RPMs, huge body of existing i386 RPMs scattered around net that 
install to bin). Ie, bin64 is the easiest answer, though i agree it's 
not the prettiest, but less ugly than what we have now. See below.

You could fix rpm to not clobber, but then how do you install either 
bad packages that contain binaries in lib related packages (eg glibc, 
undoubtedly others) or simply dont have a -lib package or install 
both i386 and x86_64 versions of software?

> /usr/bin64 is not and nobody uses it until now (both AFAIK) -- 
> google only returns 5 results. One of them:
>
> http://lists.debian.org/debian-amd64/2003/11/msg00015.html
>
> I think nobody really want a special fedora(-island)-solution in this
> area, or?  I don't want one...

Well, the king of ABI changes, IRIX on MIPS, used /usr/{bin/lib} for 
native (ie n32 for any recent IRIX) and then /usr/$ABI/ for other 
ABIs such as o32 (the deprecated 32bit MIPS ABI) and n64 (64bit). 
Packages potentially would contain executable and shared binary 
objects for multiple ABIs, and you could choose which ABIs to 
install, eg mozilla package might contain sub-packages for docs, 
config, n32 libs, n64 libs, n64 binaries and n32 binaries, you could 
install one of n32 or n64, the other or both, or install the n32 
binaries and libs and just the n64 libs (for compiling n64 and 
resolving link references against).

It worked quite well and is useful as it allows you to compile for 
ABIs even if the system does not support it (eg n64 on O2 systems, as 
you could easily install n64 bits), or to install o32 versions of 
software (eg because o32 is all that was available, or to install o32 
libraries from a package to compile against).

I dont know what the answer is, all I'm saying is:

- i386 is going to be around a long time, hence i386 packages too,
   and i'm guessing Fedora would like to support these packages with
   the minimum of fuss (the entire reason why we have lib64).

- Allowing i.86 and x86-64 packages to clobber each other's files is
   bad

- It should be possible to compile i386 packages on x86-64

- I dont know if x86_64 supports it, but if it does, it might be nice
   to be able to support x86_64 native binaries that use 32bit
   addressing (ie able to access the extra registers and the 64bit R..
   forms of x86_64 registers, but using 32bit addressing). I'm
   guessing x86_64 supports this, but that there is no ABI defined for
   it, and that there possibly never will be, but such an ABI
   potentially could be useful.

- it would be nice to be able to install both i386 and x86-64
   architecture binaries alongside each other. (for testing if nothing
   else).

the current situation is annoying, $something needs to be done. Be 
it:

- a drive to fix up packages and split up non-arch-specific, 
libraries and binaries into seperate packages and have RPM refuse to 
clobber files (by default) no matter what, as it currently does for 
files belonging to different packages of same architecture.

This would do for being able to install all the bits needed to 
support i386 binaries and be able to compile i386 versions of 
software. And I get impression it's already ongoing.

This would not address installing the different arch versions of 
essentially the same binaries.

- Define seperate directories for different ABIs.

Eg, let /bin and /lib be native. And lib/$ABI or /usr/$ABI/{bin/lib} 
or whatever. PATH and LD_LIBRARY_PATH exist for a reason ;)

This essentially would allow complete flexibility, including for 
support of future ABIs (eg an ILP32 but otherwise x86-64 long mode 
using ABI, with 64bit doubles.)

It would though require some support from rpm. At present the cpio 
archives in RPM packages contain the full path, the path would need 
to be abstracted somewhat to allow rpm to install binaries and libs 
to the correct directories for the architecture, to allow i386 to be 
installed.

One could avoid this though by defining /bin and /lib to be i386 and 
/bin64 and /lib64 for x86-64, but i agree that is ugly, as I said 
above. However it would allow x86-64 to stay compatible with the 
fairly large body of 3rd party software packaged for Fedora i386. bin 
as native and bin32 or /usr/i386 for i386 is slightly cleaner, but a 
huge compatibility problem. bin64 is ugly, but will work fine and 
allow perfect compatibility with i.86. Take your pick.

anyway, the current situation is annoying. Annoying enough to make me 
switch to the first distro that does multiarch correctly, or even 
just gets gcc -m32 right without having to clobber files. ;)

But i'd prefer to help fix it in FC, whatever the right way may be.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam at dishone.st
Fortune:
Pushing 30 is exercise enough.