FC13 nss-softokn-freebl update issues

[Robert Relyea]

On 06/01/2010 11:48 AM, Bill Nottingham wrote:
> Elio Maldonado (emaldona at redhat.com) said: 
>   
>> Not sure but I strongly suspect a change made to nss.spec to be the cause. 
>> See https://bugzilla.redhat.com/show_bug.cgi?id=596840#c7 
>>     
> It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr
> libraires) do not fit the normal library naming, so it's not explicitly pulled for
> multilib. For any update or release set that's composed with a package that explicitly
> requires a compat arch of nss-softokn-freebl (such as glibc, libpurple,
> pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13
> updates has none of these, so it doesn't.
>
> We could add some hacks to mash to get it pulled in, but I must ask...
> why do all the NSS/NSPR libraries version their libraries in the library
> name instead of the so version (i.e., libfreebl3.so instead of
> libfreebl.so.3)?
>   
Because upstream selected it's names before linux naming was anything
like widespread.

nss/nspr upstream was also unusual in considering binary compatibility
breakage a sev 1 bug. It's expected that old apps run against new versions.

One good side effect of this is there is no name colision in the
libraries between Network Security Services and Name Switch Select, nor
NSS's libssl3.so and openssl's libssl.so.

bob


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6650 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100602/d1016af5/attachment-0001.bin