Improving the way we select multilib packages for trees

Jeremy Katz katzj at redhat.com
Fri Apr 28 18:23:48 UTC 2006


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.




More information about the Fedora-maintainers mailing list