On 06/01/2010 11:48 AM, Bill Nottingham wrote:
Elio Maldonado (emaldona(a)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