Kai Engert wrote:
Matthew Miller wrote:On Tue, Aug 22, 2006 at 11:40:55PM +0200, Kai Engert wrote:A "Requires:" entry in a SPEC file may define the smallest library version acceptable for the resulting RPM package.Is it possible by some SPEC logic, to make a "Requires:" entry dynamic?In other words, is it possible, at RPM build time, to query the installed library release in the build environment, and have the produced RPM be dependent on >= that library version?Yes,How would you do that? Thanks in advance for explaining.but it shouldn't be necessary. Does the library you're linking against have issues with a broken soname?I'll write a follow up post that describes why I consider it.
I was considering this for all Mozilla applications and its Requires statement for library NSS.
The NSS library does not change its .so names , not even when exporting additional symbols in the library. The NSS project follows the rule, that when building against a certain version of the library, you should use at least that library version - or a newer version. In other words, the project follows a compatibility model, where you are always allowed to drop in a newer library release, and your application will continue to work.
Usually when new exported symbols are added, this won't introduce new dependencies for the application, when the application simply gets rebuilt. Only if the application makes use of the new symbols a new dependency will get introduced.
Now we recently ran into a situation, where an updated NSS release exported an additional symbol. NSS made use of this symbol internally. Unfortunately, it uses this symbol in a static .a library, and Mozilla links with that static library!
So when the Mozilla application got rebuilt, the dependency on the new exported symbol was implicitly added. This caused SSL to stop working in Firefox, after end users upgraded Firefox only, without upgrading the NSS package.
We identified the cause of this issue and the NSS team intends to get rid of this .a library, and convert it into an .so library in a future NSS release. This way it should no longer be possible to introduce implicit new dependencies when building against a newer NSS library release.
Until the .a library can get removed, we'll have to avoid adding new symbols in the same way again, by carefully reviewing the impact of new introduced symbols.
I asked my question to dynamize the Requires: because it would help ensure the recommendation of the NSS team, that at runtime you should use at least the version you built against.
If we used this dynamic approach, we would be able to avoid future dependency bugs like this - even if the .a lib is kept and if such a mistake happens again.
I already promised to Chris Aillon, who is the Firefox RPM maintainer, that the NSS team will look into removing the .a lib soon. But now that I have learned a dynamic Requires: is possible, I would like to propose to use this mechanism, too.
Because in addition it would ensure that end users updated to the latest security update of the NSS library, even if they intended to only update the Firefox package.
Regarding the way to do it, Rex Dieter proposed to use "nss-config --version". This looks like a good approach to me, because it avoids querying the RPM database while doing an RPM build.
Thanks, Kai
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
