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

Kai Engert kengert at redhat.com
Wed Aug 23 21:34:29 UTC 2006


Tomas Mraz wrote:
> On Wed, 2006-08-23 at 16:31 -0400, Jesse Keating wrote:
>   
>> On Wednesday 23 August 2006 16:18, Hans de Goede wrote:
>>     
>>> Actually afaik gnome and gtk have the exact same problem (they are fully
>>> backward compatible but introduce new symbols making apps using these
>>> new symbols break on older version), but there we've been plastering
>>> over the problem by manually adding Requires to packages.
>>>       
>> I just talked to some of our Gnome maintainers and they don't think that's the 
>> case at all.
>>
>> Isn't that why you have foo-so.1 and foo-so.1.1?  Your build that has 
>> foo-so.1.1 could include foo-so.1 for compat no?  Am I totally off base here?  
>> Versioned libraries are here for a reason, so that you can know what soname 
>> you're compiling against and need later on down the road.  Having random 
>> symbols in random unversioned .so files seems very very wrong to me, as a 
>> shared library.
>>     
>
> No, they would have to use versioned symbols for this purpose.
>
> See http://people.redhat.com/drepper/dsohowto.pdf section 3.
>   

Exported symbol in NSS shared libraries are tagged with the number of 
the first version that contained the symbol. I used this command to grep 
for the new symbols in the most recent FC5 update:

[root at kaiez1 tmp]# readelf -a /usr/lib/libnss3.so |grep -i 3\.11\.1
   230: 4f2ed4a0   320 FUNC    GLOBAL DEFAULT   11 
NSS_RegisterShutdown@@NSS_3.11.1
   553: 4f2ed400   151 FUNC    GLOBAL DEFAULT   11 
NSS_UnregisterShutdown@@NSS_3.11.1
   666: 4f3302e0    22 FUNC    GLOBAL DEFAULT   11 
SEC_ASN1EncodeUnsignedInt@@NSS_3.11.1
   749: 4f2f0fc0    86 FUNC    GLOBAL DEFAULT   11 
SEC_RegisterDefaultHttpCl@@NSS_3.11.1
(excerpt)

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://lists.fedoraproject.org/pipermail/devel/attachments/20060823/449a711b/attachment-0002.bin 


More information about the devel mailing list