Jarod Wilson wrote:
On Feb 25, 2008, at 5:16 PM, Andrea wrote:
SDL-devel Requires: alsa-lib-devel. Both alsa-lib-devel.ppc and
alsa-lib-devel.ppc64 Provides: alsa-lib-devel. End of story, from rpm's
perspective. Now, yum tries to be a bit brighter, and when no required
bit is installed on a multi-arch system, it'll try to get the package
that provides the required bits, of the same arch. As has been mentioned
before, multi-lib is a bit messy. RPM and package dependencies were
created long before people were running multi-lib 64-bit systems.
I see know that the architecture does not take part in the dependency resolution.
What I find really strange is not that RPM does not handle properly this situation,
but that *nowhere* in the Fedora Release Notes, nowhere in the FAQ, most common bugs,
the howto-PPC wiki page, is stated that RPM has this serious massive limitations,
that could leave your system in an unusable state.
I am a programmer too and I know very well software is not perfect and it only gets
better
with a lot of effort, so screaming is useless.
But the second bets thing, after a bug-free software, is clearly state what works and what
doesn't.
I've been writing in the Fedora Mailing List on redhat and I did not get *one* decent
answer.
I would like to benefit from your knowledge of RPM and ask you the following:
How is RPM supposed to work when 2 packages provide the same file/functionality?
Why can I install gdb.ppc and gdb.ppc64 (that provide the same files), but
alsa-lib-devel.ppc and alsa-lib-devel.ppc64 (that provide some common files) conflict?
What is the exact rule to define a "RPM file conflict"?
I guess that knowing how it works, makes it much easier to use it.
Thanks for your help.
Andrea