On Mon, 19 Jul 2004, Jeremy Katz wrote:
Except that anything that ends up with different paths for binaries isn't exactly sane ;)
Well, it's slightly less insane than the alternative, which is to have both i386 and x86_64 RPMs install binaries to the same directory. Given that the idea (i guess) was to allow installation of i386 RPMs with the minimum of pain (ie not having to go back and modify all i386 RPMs presumably), x86_64 I think possibly should have gone with bin64 directories. It would have avoided the glibc/gcc/binutils/etc.. i386/x86_64 problems where both RPMs wish to install binaries to .../bin.
I havnt yet managed to get x86_64 RPM gcc package to build -m32 binaries without installing conflicting RPMs, and in using yum to install the needed i386 packages i ended up with quite a few i386 binaries in my bin/ directories that previously had been x86_64.
Sure, you get them both installed, but switching between them is impossible (not to mention problems with things like "what does the menu item for gedit launch?")
Well, that'd be determined by PATH surely, it would even allow one to express a preference for i386 vs x86_64. How do i install both 32 and 64 bit versions of binaries?
I agree it's ugly, but it's less worse (IMHO) to have bin32 (which wouldnt work for existing i386 RPMs i guess) or else bin64 for a multiarch system, and guarantees i386 and x86_64 packages wont clobber each other (yum and rpm at moment are quite happy to allow i386 packages to clobber x86_64).
My preference in an ideal world would be for bin/, lib/ simply to be defined as always being native, maybe having a /usr/$ARCH/{bin,lib} directory scheme for i386 ABI stuff (ARCH = i386 or ia32, whatever people prefer.) or alternatively to fix up all the RPMs so that config files and docs are in seperate RPMs from libraries which should be in seperate RPMs from binaries and make rpm and/or yum not allow RPMs to clobber each other's files, regardless of arch. (the latter approach still wouldnt allow me to install both 32 and 64 versions of software though).
I dont know the answer exactly, but the current situation is annoying.
Jeremy
regards, -- Paul Jakma paul@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A warning: do not ever send email to spam@xxxxxxxxxx Fortune: This life is a test. It is only a test. Had this been an actual life, you would have received further instructions as to what to do and where to go.
