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
Elio
----- Original Message ----- From: "Jonathan Underwood" jonathan.underwood@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Saturday, May 29, 2010 1:48:38 AM GMT -08:00 US/Canada Pacific Subject: Re: FC13 nss-softokn-freebl update issues
On 29 May 2010 05:57, Ralf Corsepius rc040203@freenet.de wrote:
Hi,
ATM, I am observing this:
# repoquery -qa 'nss-softokn-freebl*' nss-softokn-freebl-0:3.12.4-19.fc13.x86_64 nss-softokn-freebl-0:3.12.4-17.fc13.i686 nss-softokn-freebl-devel-0:3.12.4-19.fc13.x86_64 nss-softokn-freebl-devel-0:3.12.4-19.fc13.i686
http://download.fedora.redhat.com/pub/fedora/linux/updates/13/x86_64/nss-sof...
exists, but yum's primary* doesn't seem to contain it:
zcat 4bcc071c3c3a7ca4116f222b62c7e01774a98b32244cf0a73245437ac7579f23-primary.xml.gz | grep nss-softokn-freebl | grep href
<location href="nss-softokn-freebl-devel-3.12.4-19.fc13.i686.rpm"/> <location href="nss-softokn-freebl-3.12.4-19.fc13.x86_64.rpm"/> <location href="nss-softokn-freebl-devel-3.12.4-19.fc13.x86_64.rpm"/>
Seems as a bogusly "blacklisted i686" package to me.
The problem with this: glibc2.i686 requires nss-softokn-freebl
Something else a bit weird, not sure if it's related:
# yum check all Loaded plugins: presto, refresh-packagekit nss-softokn-3.12.4-19.fc13.x86_64 is a duplicate with nss-softokn-3.12.4-17.fc13.i686 nss-softokn-freebl-3.12.4-19.fc13.x86_64 is a duplicate with nss-softokn-freebl-3.12.4-17.fc13.i686 Error: check all
Elio Maldonado (emaldona@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
On 06/01/2010 11:48 AM, Bill Nottingham wrote:
Elio Maldonado (emaldona@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
Robert Relyea (rrelyea@redhat.com) said:
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.
OK. Copying from the bug:
There are two 'simple' fixes for this that don't involve hotfixing the push infrastructure:
1) For all nss/nspr packages that don't have .so symlinks in their devel packages, add %{?_isa} to the requires in the devel packages.
See https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires for a packaging draft for this.
For example, that would change, in nss-softokn-freebl-devel:
Requires: nss-softokn-freebl = %{version}-%{release} to: Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release}
in nss-softokn-freebl-devel,
Requires: nss-softokn = %{version}-%{release} to Requires: nss-softokn%{?_isa} = %{version}-%{release}
in nss-softokn-devel, and so on.
The reason this is needed is that for most -devel pacakges, there is automatic dependencies added on the proper library package due to following the '.so' devel symlink to the main library. This doesn't work for nss/nspr, as the -devel packages don't have these symlinks.
2) Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 or https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to stable, as those will pull in the i686 nss-softokn-freebl through library dependencies.
Bill
On 06/02/2010 12:51 PM, Bill Nottingham wrote:
Robert Relyea (rrelyea@redhat.com) said:
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.
OK. Copying from the bug:
There are two 'simple' fixes for this that don't involve hotfixing the push infrastructure:
- For all nss/nspr packages that don't have .so symlinks in their devel
packages, add %{?_isa} to the requires in the devel packages.
See https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires for a packaging draft for this.
For example, that would change, in nss-softokn-freebl-devel:
Requires: nss-softokn-freebl = %{version}-%{release} to: Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release}
in nss-softokn-freebl-devel,
Requires: nss-softokn = %{version}-%{release} to Requires: nss-softokn%{?_isa} = %{version}-%{release}
in nss-softokn-devel, and so on.
The reason this is needed is that for most -devel pacakges, there is automatic dependencies added on the proper library package due to following the '.so' devel symlink to the main library. This doesn't work for nss/nspr, as the -devel packages don't have these symlinks.
- Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 or
https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to stable, as those will pull in the i686 nss-softokn-freebl through library dependencies.
Thank you Bill.
Elio
Bill
Elio Maldonado (emaldona@redhat.com) said:
- Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 or
https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to stable, as those will pull in the i686 nss-softokn-freebl through library dependencies.
Thank you Bill.
Further research shows that the pidgin update will *not* help this particular situation, as pidgin/libpurple 2.7.x has dropped its dependency on nss-softokn-freebl.
Bill