Re: FC13 nss-softokn-freebl update issues

[Elio Maldonado]

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" 
To: "Development discussions related to Fedora" 
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  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

FC13 nss-softokn-freebl update issues

[Bill Nottingham]

Elio Maldonado ([e-mail]) 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

FC13 nss-softokn-freebl update issues

[Robert Relyea]

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

FC13 nss-softokn-freebl update issues

[Bill Nottingham]

Robert Relyea ([e-mail]) 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

FC13 nss-softokn-freebl update issues

[Elio Maldonado]

On 06/02/2010 12:51 PM, Bill Nottingham wrote:
> Robert Relyea ([e-mail]) 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

FC13 nss-softokn-freebl update issues

[Bill Nottingham]

Elio Maldonado ([e-mail]) 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