If you're a user on x86_64, you've probably noticed the less than ideal way in which packages are chosen for being shipped in both x86 and x86_64 forms. Originally, the policy was just the LSB set. Then, it was expanded to be "most" libraries based on the contents of a file used at tree compose time. Now, it's time for the next expansion and actually getting to where we ship a 32-bit development environment on x86_64. To do so, we're going to change to using the existence of a -devel package to say that we should be shipping multiple arches of a package. I've just built a new version of RPM containing a patch so that the -devel packages will end up requiring the correct library package[1]. What does this mean to you as a package maintainer? In a lot of cases, hopefully nothing. But there are cases where header files included in packages are generated at build-time and have an architecture or build specific nature. These conflicts will need to be fixed similar to how things have been fixed for runtime library issues -- either moving files around or removing the cause for the difference. If there is a valid reason for them to be different, then you might want to explore having a common stub header that includes the different headers as appropriate (eg, how /usr/include/gnu/stubs.h is handled) You'll need to finish fixing these in time for the Test1 freeze on June 7th so that we can have a sane tree. Also, note that while we're not going down the road of starting to pull x86 packages into the x86_64 trees for Extras yet, there is interest in having this available, so it would be valuable to go ahead and look into potential problems there now as I'd really like to have our multilib package set policy more consistent for Fedora Core 6. Thanks, Jeremy [1] Basically, we resolve the soname of the target of the libfoo.so devel symlink and make that a requires of the package.
