I'm the project coordinator of the sipXpbx project [1] and we're distributing quite a number of RPMs (in the fullness of time we'd like to get them into Extras, but that is a topic for another list and another day) . The project itself consists of several component RPMs and there are some other open source projects on which we depend that we build RPMs for, mostly because they don't. The one exception to the "mostly because they don't" is the difficulty I'm looking for advice on from those who understand packaging.
Fedora Core inludes w3c-libwww.rpm, but that version does not include compilation with openssl. For lots of good reasons, we need the openssl, so we build a version of the w3c-libwww.rpm that has it enabled; that's the only difference.
Our first approach to dealing with the conflict was just to instruct our users to configure yum to exclude the w3c-libwww package from all repositories but ours, but that's a bit of a pain.
We tried adding a 'requires' line to our spec file that called for 'libwwwssl.so' (which is in our rpm but not the Core rpm for the same package), but then yum seemed to want to load both...
In any event, this seems to me to raise a general issue of how to cope with the fact that some packages can be built in (potentially overlapping) variants. How can we make all of the variants available and express what each provides so that tools like yum can make the correct choice?
[1] http://www.sipfoundry.org/sipXpbx/
On Wed, 2005-02-23 at 15:22 -0500, Scott Lawrence wrote:
Fedora Core inludes w3c-libwww.rpm, but that version does not include compilation with openssl. For lots of good reasons, we need the openssl, so we build a version of the w3c-libwww.rpm that has it enabled; that's the only difference.
In this case, this is a bug in Fedora Core's w3c-libwww package. I can't think of a good reason for it not to depend on openssl, since it should be present on the vast majority of installs (and isn't an unreasonable dependency when installing w3c-libwww).
In any event, this seems to me to raise a general issue of how to cope with the fact that some packages can be built in (potentially overlapping) variants. How can we make all of the variants available and express what each provides so that tools like yum can make the correct choice?
One of the hard and fast rules I intend to implement is that Fedora Extras packages cannot duplicate existing packages in Fedora Core.
Please open a bug against bugzilla.redhat.com to get w3c-libwww to start building with ssl enabled, and by FC4, this issue should be moot. :)
Otherwise we either start hacking conflict overrides, or we end up with rpms that have renamed libraries, effectively doubling the number of libraries on a system.
The Red Hat package maintainers are willing to fix issues in their Core packages, and Fedora moves fast enough that it should never be a problem for more than 6 months. (And if the maintainers aren't willing, me and Greg can start beating them over the head with the cluestick)
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Wed, 2005-02-23 at 14:28 -0600, Tom 'spot' Callaway wrote:
One of the hard and fast rules I intend to implement is that Fedora Extras packages cannot duplicate existing packages in Fedora Core.
A good rule, I agree.
Please open a bug against bugzilla.redhat.com to get w3c-libwww to start building with ssl enabled, and by FC4, this issue should be moot. :)
Done.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149536
packaging@lists.fedoraproject.org
-
Scott Lawrence -
Tom Callaway