On 7/6/05, Bob Proulx <[EMAIL PROTECTED]> wrote: [RedHat x86_64] Thanks for your insight in the RedHat way. With already three OSes installed on my AMD64, I don't feel like trying another one (an Solaris 10 would be first anyway), but their approach is definitely relevant for us. Both as an example and as a "de facto" standard.
> That listing lists both packages back to back. Each zlib package has > two parts. One is architecture dependent, the /usr/lib/lib*so* part. > The other is architecture independent, the /usr/share part. > > This is where it gets ugly. The /usr/share part overlaps between the > two packages. Correct. I remember Slackware did that, too, in the old days, and it is very ugly. The better way to do it is to have three (sub)packages: i386, x86_64 and shared. That is a bit like -common and -bin, but the packages differ only in architecture, not in the name. Imho that is the way to go. However, if you look closer, you find that both approaches impose the same restrictions: all two or three (sub)packages have to be exactly the same version, they have to match. So you can't upgrade one without upgrading the other(s). I think this severely limits the ability to install third-party i386 software on a RedHat x86_64 system. As soon as the third-party software requires a library upgrade, you get conflicts. (Now that problem isn't new either, it is the reason behind DLL hell...) > But remove one of the packages and that file is removed, > leaving the other package in a broken state without that particular > file. That is bizarre. Slackware could handle this case 11 (!) years ago. > These two biarch packages are almost but not quite required to be in > lockstep. It is possible to upgrade one without the other as long as > the shared files have the same md5sum. Hm... which probably equates to never :-) > This is equivalent, but > different, to a 32-bit chroot on Debian because it has all of the > files in individual packages as the actual 32-bit versions. A chroot solves the interlocking problem, at the expensive of a massive waste of disk space and cumbersome usability. I wonder whether it would be worth making a chroot more user friendly... Thomas
