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

[Kai Engert]

Jesse Keating wrote:
> On Wednesday 23 August 2006 14:12, Kai Engert wrote:
>   
>> 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.
>>     
>
> Alternatively in OUR packaging of nss, we could move it from .so to a 
> versioned library based on the version of nss we're building.  Then have 
> firefox and friends link against the versioned library we create...
>   

In your alternative proposal, would you change the .so name each time a 
new symbol gets added?

Fictionary sequence of events (in your alternative proposal):
- NSS 3.11.1 with nss.so.3.11.1 gets released, along with gaim 1.5, 
which links against nss.so.3.11.1
- NSS 3.11.2 gets released with nss.so.3.11.2
- nss.so.3.11.1 is no longer available
- as a consequence you would need to rebuilt gaim, in order to make it 
link against nss.so.3.11.2

But there is absolutely no real need to rebuild gaim, because of NSS' 
promise that you are allowed to drop in (at runtime) any later version 
and it will run just fine.

I believe your alternative proposal unnecessarily introduces the need to 
rebuild applications. Let's suppose we have 10 applications that link in 
NSS, I believe your proposal requires us to rebuild all those 10 
applications, each time a NSS release with additional symbols gets released.

And it would make our life more difficult, because of having to maintain 
the versioned .so filenames as a difference to the upstream project.

If I misunderstood, please elaborate.

I believe the earlier proposal to dynamically adjust the Requires: for 
the minimum allowed NSS version is much simpler, it causes no manual 
work, a one time spec file change will fix it for all future releases. 
And it will minimize the amount of packages that need to get rebuilt and 
will actually depend on the more recent NSS releases - to only those 
applications that got rebuilt for a reason.

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/e7246624/attachment.bin>