Re: multiarch/bi-arch status (ETA) question
On 7/6/05, Bob Proulx <bob@proulx.com> 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
Reply to: