Hi, everyone. I was asked at the last QA meeting to send a summary of
the nss-softokn dependency problem that emerged in Fedora 13 recently to
this list, so we can - if possible - try to ensure the AutoQA tests are
capable of detecting this kind of problem.
The problem was that, when an nss-softokn update was pushed for F13, the
updated i686 packages were not pushed to the x86-64 updates repository.
The original nss-softokn i686 packages, however, *are* in the x86-64
repo. So you hit trouble if you run the x86-64 version of Fedora and
have both x86-64 and i686 nss-softokn packages installed, which can
easily happen as part of a dependency chain when installing a 32-bit
package. When you went to an update, you would have an updated x86-64
package available but not an updated i686 package, which caused
problems.
The cause as described by Bill Nottingham in the ml thread:
"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."
Bill's recommended fix (from the bug report,
https://bugzilla.redhat.com/show_bug.cgi?id=596840 ):
"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. "
The critical thing to note here is that the bug is only apparent if you
look at which packages are (going to be) sent to which repositories when
the update is published. If you just look at the packages actually
generated as part of the update, you're unlikely to be able to catch the
problem. What we need to be able to check is that, if a given package's
32-bit build is available in the 64-bit release repository, when that
package is updated, the process will publish the 32-bit build to the
64-bit update repository. If not, we have trouble.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net