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@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A warning: do not ever send email to spam@xxxxxxxxxx Fortune: Pushing 30 is exercise enough.
