I don't know when the 3 suffix was added. It may have been due to versioning at some
time but if I recall correctly we keep the 3 suffix to avoid a name class with with the
other nss package (name switch service I believe). Bob or Kai can set me straight on this
matter.
Another thing that puzzles me if that this is a problem on F-13 but not on F-12. See
comments in
https://bugzilla.redhat.com/show_bug.cgi?id=596840
Elio
----- Original Message -----
From: "Bill Nottingham" <notting(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Tuesday, June 1, 2010 11:48:41 AM GMT -08:00 US/Canada Pacific
Subject: Re: FC13 nss-softokn-freebl update issues
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)?
Bill
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel