On Thursday 11 December 2003 17:08, Bryan O'Sullivan wrote:
There's a hack in place in the latest Red Hat version of RPM that basically chooses 64-bit binaries in preference to 32-bit binaries when there's a conflict. This hack seems to apply to docs, too, but not to some other kinds of files such as scripts. The result is that many packages (glibc being one) can cleanly have 32-bit and 64-bit packages installed simultaneously, but others can't be installed bi-arch without some crowbar work due to having inter-package dependencies that break them (XFree86 was this way last time I checked).
One of the great attractions of the AMD64 (at least to me) is the ability to run "old" 32 bit applications at the same time (on the same system) I am running 64 bit applications.
This works out well in practice for many applications, once you have the base system installed properly and the ragged edges beaten into shape. I'm sure those ragged edges will get worked out over the next several months.
Yes but ... I wonder how things will work when you need to update both the 32 bit and 64 bit versions of packages vis up2date (or whatever it becomes).
The AMD64 systems are the only one currently supported by Red Hat that seem to have this bimodal capability (the Sparc is not supported any longer). I have no idea if the ppc64 or the s390z can concurrently run 32 bit applications.
One solution could be to breakup (make more granular) some of the packages to move the conflicting files into a separate binary package BUT that has to be a messy solution.
While the processing of getting Fedora Core "working" for AMD64 may be a bit messy and require some crowbaring to work, maybe (I hope, I hope, I hope), Fedora Core 2 may be able to be out in two architectures.