Is it possible to dynamize "requires" at RPM build time?

[Kai Engert]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3248 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060823/c8ec2f53/attachment.bin>