Adding Elio for awareness.

Openjdk packages should depend exactly on the same version of NSS they were build against. Currently I don't know how to implement this properly automatically. 
Appearently rpms autogenerated soname depndenci is not enough

Second - more serious issue is, what troubles can cause dependency on exact version of NSS. At worst, It may lock system to prevent updates of NSS.  If >= will be used, then it may hit this bug again.

Testing with:


--- a/java-1.8.0-openjdk.spec
+++ b/java-1.8.0-openjdk.spec
@@ -95,6 +95,8 @@
 %global NSS_LIBDIR %(pkg-config --variable=libdir nss)
 %global NSS_LIBS %(pkg-config --libs nss)
 %global NSS_CFLAGS %(pkg-config --cflags nss-softokn)
+# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
+%global NSS_BUILDTIME_VERSION %(rpm -q nss | grep `uname -i` | sed s/.`uname -i`//  | sed s/nss-//)
 
 # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
 %global _privatelibs libmawt[.]so.*
@@ -666,6 +668,8 @@ Requires: javapackages-tools
 Requires: tzdata-java >= 2015d
 # libsctp.so.1 is being `dlopen`ed on demand
 Requires: lksctp-tools
+# there is need to depnd on exact version of nss
+Requires: nss >= %{NSS_BUILDTIME_VERSION}
 # tool to copy jdk's configs - should be Recommends only, but then only dnf/yum eforce it, not rpm transaction and so no configs are persisted when pure rpm -u is run. I t may be consiedered as regression
 Requires:      copy-jdk-configs >= 1.1-3
 OrderWithRequires: copy-jdk-configs

(In reply to jiri vanek from comment #3)
> Testing with:
> 
> 
> --- a/java-1.8.0-openjdk.spec
> +++ b/java-1.8.0-openjdk.spec
> @@ -95,6 +95,8 @@
>  %global NSS_LIBDIR %(pkg-config --variable=libdir nss)
>  %global NSS_LIBS %(pkg-config --libs nss)
>  %global NSS_CFLAGS %(pkg-config --cflags nss-softokn)
> +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> +%global NSS_BUILDTIME_VERSION %(rpm -q nss | grep `uname -i` | sed
> s/.`uname -i`//  | sed s/nss-//)
>  
>  # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
>  %global _privatelibs libmawt[.]so.*
> @@ -666,6 +668,8 @@ Requires: javapackages-tools
>  Requires: tzdata-java >= 2015d
>  # libsctp.so.1 is being `dlopen`ed on demand
>  Requires: lksctp-tools
> +# there is need to depnd on exact version of nss
> +Requires: nss >= %{NSS_BUILDTIME_VERSION}
>  # tool to copy jdk's configs - should be Recommends only, but then only
> dnf/yum eforce it, not rpm transaction and so no configs are persisted when
> pure rpm -u is run. I t may be consiedered as regression
>  Requires:      copy-jdk-configs >= 1.1-3
>  OrderWithRequires: copy-jdk-configs


%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would be simpler. Either way, we need to check nss-softokn as well, as the two can be different, and it's softokn that provides the freebl library.

$ rpm -q nss-softokn
nss-softokn-3.16.2.3-13.el7_1.x86_64
$ rpm -q nss
nss-3.19.1-19.el7_2.x86_64

SunEC link step:

/usr/bin/g++ -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -fuse-ld=gold -Xlinker -z -Xlinker defs -Xlinker -O1 -shared -L/home/andrew/builder/icedtea8/openjdk.build-boot/jdk/lib/amd64 -L/home/andrew/builder/icedtea8/openjdk.build-boot/jdk/lib/amd64/server   -Xlinker -version-script=/home/andrew/builder/icedtea8/openjdk-boot/jdk/make/mapfiles/libsunec/mapfile-vers -Xlinker -soname=libsunec.so -o /home/andrew/builder/icedtea8/openjdk.build-boot/jdk/lib/amd64/libsunec.so /home/andrew/builder/icedtea8/openjdk.build-boot/jdk/objs/libsunec/ECC_JNI.o  -lstdc++  -lc -lfreebl -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4

(In reply to jiri vanek from comment #2)
> Openjdk packages should depend exactly on the same version of NSS they were
> build against. Currently I don't know how to implement this properly
> automatically. 
> Appearently rpms autogenerated soname depndenci is not enough
> 
> Second - more serious issue is, what troubles can cause dependency on exact
> version of NSS. At worst, It may lock system to prevent updates of NSS.  If
> >= will be used, then it may hit this bug again.

Another danger is, that once openjdk is built in brew agianst some exactversion of NSS, then one can not update Openjdk, before also NSS reach stbale. And NSS is updated pretty often...

> %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would

Thanx

> be simpler. Either way, we need to check nss-softokn as well, as the two can
> be different, and it's softokn that provides the freebl library.

Are you sure with "as well"? I would say only nss-softokn, then?
> 
> $ rpm -q nss-softokn
> nss-softokn-3.16.2.3-13.el7_1.x86_64
> $ rpm -q nss
> nss-3.19.1-19.el7_2.x86_64
> 

Still I'm very afraid to push this change.

diff --git a/java-1.8.0-openjdk.spec b/java-1.8.0-openjdk.spec
index 1bb855a..c372812 100644
--- a/java-1.8.0-openjdk.spec
+++ b/java-1.8.0-openjdk.spec
@@ -95,6 +95,9 @@
 %global NSS_LIBDIR %(pkg-config --variable=libdir nss)
 %global NSS_LIBS %(pkg-config --libs nss)
 %global NSS_CFLAGS %(pkg-config --cflags nss-softokn)
+# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
+%global NSSSOFTOKN_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn)
+%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
 
 # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
 %global _privatelibs libmawt[.]so.*
@@ -666,6 +669,9 @@ Requires: javapackages-tools
 Requires: tzdata-java >= 2015d
 # libsctp.so.1 is being `dlopen`ed on demand
 Requires: lksctp-tools
+# there is need to depnd on exact version of nss
+Requires: nss >= %{NSS_BUILDTIME_VERSION}
+Requires: nss-softokn >= %{NSSSOFTOKN_BUILDTIME_VERSION}
 # tool to copy jdk's configs - should be Recommends only, but then only dnf/yum eforce it, not rpm transaction and so no configs are persisted when pure rpm -u is run. I t may be consiedered as regression
 Requires:      copy-jdk-configs >= 1.1-3
 OrderWithRequires: copy-jdk-configs

This approach
> +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> +%global NSSSOFTOKN_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn)
> +%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
> +# there is need to depnd on exact version of nss
> +Requires: nss >= %{NSS_BUILDTIME_VERSION}
> +Requires: nss-softokn >= %{NSSSOFTOKN_BUILDTIME_VERSION}

Do not count release flag of package. Form the locking restrictions it is much better, but from point of this bug.. hard to say if it can bait again.

oook.. pushed to f25. Lest see

(In reply to jiri vanek from comment #6)
> > %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would
> 
> Thanx
> 
> > be simpler. Either way, we need to check nss-softokn as well, as the two can
> > be different, and it's softokn that provides the freebl library.
> 
> Are you sure with "as well"? I would say only nss-softokn, then?
> > 
> > $ rpm -q nss-softokn
> > nss-softokn-3.16.2.3-13.el7_1.x86_64
> > $ rpm -q nss
> > nss-3.19.1-19.el7_2.x86_64
> > 
> 
> Still I'm very afraid to push this change.

I'm not in favour of it either, I was just making sure you covered all bases if you did push this. Such a change is a kludge to fix what is inherent breakage in the packaging system.

For a package, x, there is a set of build dependencies, y. As I understand it, the issue here is that x was built against y, a subset of which, z, were not yet released in Fedora. Package x was then released before the full set, y, and thus you end up with this problem that x is being run against versions of packages in y that were not those that it was built against.

That's the problem. The fact that, in many cases, problems don't appear because of sonames, missing symbols or just pure luck, is really a band aid around this underlying issue. It's not specific to OpenJDK, nor to Fedora, but a potential problem you will run into in any situation where you run a binary against a different set of dependent binaries to those it was built against.

In contrast, RHEL packages are built against a known set of *released* packages. Exceptions are occasionally made to this, but they come either from a build being pushed to the buildroot from an erratum (which means it's scheduled to go out as part of the associated release) or release management (which I presume know what they're doing in such cases). This bug suggests that Fedora isn't as strict in this regard.

In this case, we know NSS is part of z, but there could be other packages too. The reason we see a problem with NSS is because SunEC is built from a strange cocktail of static and linked libraries. freebl, from nss-softokn, is statically compiled into the provider because that's the only way the EC routines used are provided. However, these routines then called out to shared code in the NSS libraries. Thus, you get an issue like this where the newer freebl used by the OpenJDK build is calling out to an older set of shared NSS libraries.

That wouldn't be possible if OpenJDK wasn't being built against a nss-softokn that hadn't yet been released, as the correct NSS would be picked up either before or at the same time as the OpenJDK update. There are other possible cases where this could cause issues. Imagine some code has behaviour which is dependent on a define in a header file. In many cases, this would be for a new API call and so would be caught by a missing symbol, but it could also be because they wanted to implement different behaviour depending on whether the symbol was present or not, or had a specific value. If one decision is made at build-time based on one header, and then you try to use it at run-time against a different version, you'll again get problems. Not everything can be caught by symbols and sonames, especially as more packages use languages other than C and C++.

What your fix is essentially doing is providing the beginnings of a guarantee that at least the version used to build will be available. That shouldn't be something individual packagers need to do, but something that should be inherent in the way Fedora provides packages to users.

(In reply to jiri vanek from comment #8)
> This approach
> > +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> > +%global NSSSOFTOKN_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn)
> > +%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
> > +# there is need to depnd on exact version of nss
> > +Requires: nss >= %{NSS_BUILDTIME_VERSION}
> > +Requires: nss-softokn >= %{NSSSOFTOKN_BUILDTIME_VERSION}
> 
> Do not count release flag of package. Form the locking restrictions it is
> much better, but from point of this bug.. hard to say if it can bait again.

If something important is differing merely because of the release number, then I'd suggest some serious words with the maintainer of that package. That suggests a significant derivation from the reported upstream version, which I believe goes against Fedora policy.

The mock build did nto behaved as expected. The rewuires are counted in during srpm cration, and in such, no NSS is on the system. Different way must be found.

(In reply to Andrew John Hughes from comment #10)
> (In reply to jiri vanek from comment #6)
> > > %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss-softokn) would
> > 
> > Thanx
> > 
> > > be simpler. Either way, we need to check nss-softokn as well, as the two can
> > > be different, and it's softokn that provides the freebl library.
> > 
> > Are you sure with "as well"? I would say only nss-softokn, then?
> > > 
> > > $ rpm -q nss-softokn
> > > nss-softokn-3.16.2.3-13.el7_1.x86_64
> > > $ rpm -q nss
> > > nss-3.19.1-19.el7_2.x86_64
> > > 
> > 
> > Still I'm very afraid to push this change.
> 
> I'm not in favour of it either, I was just making sure you covered all bases
> if you did push this. Such a change is a kludge to fix what is inherent
> breakage in the packaging system.
> 
> For a package, x, there is a set of build dependencies, y. As I understand
> it, the issue here is that x was built against y, a subset of which, z, were
> not yet released in Fedora. Package x was then released before the full set,
> y, and thus you end up with this problem that x is being run against
> versions of packages in y that were not those that it was built against.
> 

Yes, that was I realised initial comments.

> That's the problem. The fact that, in many cases, problems don't appear
> because of sonames, missing symbols or just pure luck, is really a band aid
> around this underlying issue. It's not specific to OpenJDK, nor to Fedora,
> but a potential problem you will run into in any situation where you run a
> binary against a different set of dependent binaries to those it was built
> against.
> 
> In contrast, RHEL packages are built against a known set of *released*
> packages. Exceptions are occasionally made to this, but they come either
> from a build being pushed to the buildroot from an erratum (which means it's
> scheduled to go out as part of the associated release) or release management
> (which I presume know what they're doing in such cases). This bug suggests
> that Fedora isn't as strict in this regard.
> 
> In this case, we know NSS is part of z, but there could be other packages
> too. The reason we see a problem with NSS is because SunEC is built from a
> strange cocktail of static and linked libraries. freebl, from nss-softokn,
> is statically compiled into the provider because that's the only way the EC
> routines used are provided. However, these routines then called out to
> shared code in the NSS libraries. Thus, you get an issue like this where the
> newer freebl used by the OpenJDK build is calling out to an older set of
> shared NSS libraries.
> 
> That wouldn't be possible if OpenJDK wasn't being built against a
> nss-softokn that hadn't yet been released, as the correct NSS would be
> picked up either before or at the same time as the OpenJDK update. There are
> other possible cases where this could cause issues. Imagine some code has
> behaviour which is dependent on a define in a header file. In many cases,
> this would be for a new API call and so would be caught by a missing symbol,
> but it could also be because they wanted to implement different behaviour
> depending on whether the symbol was present or not, or had a specific value.
> If one decision is made at build-time based on one header, and then you try
> to use it at run-time against a different version, you'll again get
> problems. Not everything can be caught by symbols and sonames, especially as
> more packages use languages other than C and C++.
> 
> What your fix is essentially doing is providing the beginnings of a
> guarantee that at least the version used to build will be available. That
> shouldn't be something individual packagers need to do, but something that
> should be inherent in the way Fedora provides packages to users.

Well, yes. Yo are right.  As my hack did not worked, I'm currently out of ideas how to fix it.

I dont know if fedora is capable of what you suggested. To restrict buildroots to known released software may be really tricky.

(In reply to jiri vanek from comment #12)
> The mock build did nto behaved as expected. The rewuires are counted in
> during srpm cration, and in such, no NSS is on the system. Different way
> must be found.

Can you clarify what you mean by this? What exactly breaks?

$ rpm -q --requires java-1.8.0-openjdk-headless | grep nss
libnss3.so()(64bit)
libnss3.so(NSS_3.2)(64bit)
libnssutil3.so()(64bit)
libnssutil3.so(NSSUTIL_3.12)(64bit)
$ rpm -q --whatprovides 'libnss3.so()(64bit)'
nss-3.23.0-1.0.fc23.x86_64
$ rpm -q --whatprovides 'libnssutil3.so()(64bit)'
nss-util-3.23.0-1.0.fc23.x86_64
$ rpm -q --whatprovides 'libnssutil3.so(NSSUTIL_3.12)(64bit)'
nss-util-3.23.0-1.0.fc23.x86_64
$ rpm -q --whatprovides 'libnss3.so(NSS_3.2)(64bit)'
nss-3.23.0-1.0.fc23.x86_64

So the auto-requires are not enough, because nss-softokn is not required.

I dont have logs anymore, but generally this is what happened:
declared are:
%global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
...
Requires: nss >= %{NSS_BUILDTIME_VERSION}

However - the Requires are recognized during srpm creation, and that is done in minimal buildroot, before buildrequires are installed.
So pkg-config --modversion nss exit with error, no nss installed, and build fails.

if changed to something like:
%global NSS_BUILDTIME_VERSION >= %(pkg-config --modversion nss ||:)
Requires: nss %{NSS_BUILDTIME_VERSION}

Then builds pass, but no correct nss requirement is there.  Ihave now few more ideas to try, so I will investigate.

Generally, what do you think about this issue?

(In reply to Severin Gehwolf from comment #14)
> (In reply to jiri vanek from comment #12)
> > The mock build did nto behaved as expected. The rewuires are counted in
> > during srpm cration, and in such, no NSS is on the system. Different way
> > must be found.
> 
> Can you clarify what you mean by this? What exactly breaks?

(In reply to Severin Gehwolf from comment #15)
> $ rpm -q --requires java-1.8.0-openjdk-headless | grep nss
> libnss3.so()(64bit)
> libnss3.so(NSS_3.2)(64bit)
> libnssutil3.so()(64bit)
> libnssutil3.so(NSSUTIL_3.12)(64bit)
> $ rpm -q --whatprovides 'libnss3.so()(64bit)'
> nss-3.23.0-1.0.fc23.x86_64
> $ rpm -q --whatprovides 'libnssutil3.so()(64bit)'
> nss-util-3.23.0-1.0.fc23.x86_64
> $ rpm -q --whatprovides 'libnssutil3.so(NSSUTIL_3.12)(64bit)'
> nss-util-3.23.0-1.0.fc23.x86_64
> $ rpm -q --whatprovides 'libnss3.so(NSS_3.2)(64bit)'
> nss-3.23.0-1.0.fc23.x86_64
> 
> So the auto-requires are not enough, because nss-softokn is not required.

If I read the versions correctly, then adding requires nss-softoken will not be enough. Why do you think it will be?

jsutfyi:

trying something like:
+# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
+%global NSSSOFTOKN_BUILDTIME_NUMBER %(pkg-config --modversion nss-softokn || : )
+%global NSS_BUILDTIME_NUMBER %(pkg-config --modversion nss || : )
+#this is worakround for processing of requires during srpm creation
+%global NSSSOFTOKN_BUILDTIME_VERSION %(if [ "x%{NSSSOFTOKN_BUILDTIME_NUMBER}" == "x" ] ; then echo "" ;else echo ">= %{NSSSOFTOKN_BUILDTIME_NUMBER}" ;fi)
+%global NSS_BUILDTIME_VERSION %(if [ "x%{NSS_BUILDTIME_NUMBER}" == "x" ] ; then echo "" ;else echo ">= %{NSS_BUILDTIME_NUMBER}" ;fi)
+
 
 # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
 %global _privatelibs libmawt[.]so.*
@@ -666,6 +673,9 @@ Requires: javapackages-tools
 Requires: tzdata-java >= 2015d
 # libsctp.so.1 is being `dlopen`ed on demand
 Requires: lksctp-tools
+# there is need to depnd on exact version of nss
+Requires: nss %{NSS_BUILDTIME_VERSION}
+Requires: nss-softokn %{NSSSOFTOKN_BUILDTIME_VERSION}


As I'm really not sure how macros are cached between srpm ops, and final rpm ops.

(In reply to jiri vanek from comment #16)
> I dont have logs anymore, but generally this is what happened:
> declared are:
> %global NSS_BUILDTIME_VERSION %(pkg-config --modversion nss)
> ...
> Requires: nss >= %{NSS_BUILDTIME_VERSION}
> 
> However - the Requires are recognized during srpm creation, and that is done
> in minimal buildroot, before buildrequires are installed.
> So pkg-config --modversion nss exit with error, no nss installed, and build
> fails.

I'd think this is because the pkg-config runs as part of the preamble (i.e. when the spec file gets parsed). That makes some sense, thanks.

> if changed to something like:
> %global NSS_BUILDTIME_VERSION >= %(pkg-config --modversion nss ||:)
> Requires: nss %{NSS_BUILDTIME_VERSION}
> 
> Then builds pass, but no correct nss requirement is there.  Ihave now few
> more ideas to try, so I will investigate.
> 
> Generally, what do you think about this issue?

Not sure, really. It sounds like we need to hard-code the required version and manually update it when deps change and openjdk gets rebuilt.

(In reply to jiri vanek from comment #17)
> (In reply to Severin Gehwolf from comment #15)
> > $ rpm -q --requires java-1.8.0-openjdk-headless | grep nss
> > libnss3.so()(64bit)
> > libnss3.so(NSS_3.2)(64bit)
> > libnssutil3.so()(64bit)
> > libnssutil3.so(NSSUTIL_3.12)(64bit)
> > $ rpm -q --whatprovides 'libnss3.so()(64bit)'
> > nss-3.23.0-1.0.fc23.x86_64
> > $ rpm -q --whatprovides 'libnssutil3.so()(64bit)'
> > nss-util-3.23.0-1.0.fc23.x86_64
> > $ rpm -q --whatprovides 'libnssutil3.so(NSSUTIL_3.12)(64bit)'
> > nss-util-3.23.0-1.0.fc23.x86_64
> > $ rpm -q --whatprovides 'libnss3.so(NSS_3.2)(64bit)'
> > nss-3.23.0-1.0.fc23.x86_64
> > 
> > So the auto-requires are not enough, because nss-softokn is not required.
> 
> If I read the versions correctly, then adding requires nss-softoken will not
> be enough. Why do you think it will be?

Having an un-versioned requirement on nss-softokn is an improvement. I was merely pointing out that we don't have any requires on nss-softokn as of yet (but understanding the issue correctly, we should have a requirement on it).

You can alter the requires generator to output what you want:
%global _use_internal_dependency_generator 0
%global __find_requires bash -c '%{__find_requires} && echo "nss >= `pkg-config --modversion nss`"'

I don't know how much of a hack it is, though. Use with caution.

(In reply to jiri vanek from comment #18)
> jsutfyi:
> 
> trying something like:
> +# see https://bugzilla.redhat.com/show_bug.cgi?id=1332456
> +%global NSSSOFTOKN_BUILDTIME_NUMBER %(pkg-config --modversion nss-softokn
> || : )
> +%global NSS_BUILDTIME_NUMBER %(pkg-config --modversion nss || : )
> +#this is worakround for processing of requires during srpm creation
> +%global NSSSOFTOKN_BUILDTIME_VERSION %(if [
> "x%{NSSSOFTOKN_BUILDTIME_NUMBER}" == "x" ] ; then echo "" ;else echo ">=
> %{NSSSOFTOKN_BUILDTIME_NUMBER}" ;fi)
> +%global NSS_BUILDTIME_VERSION %(if [ "x%{NSS_BUILDTIME_NUMBER}" == "x" ] ;
> then echo "" ;else echo ">= %{NSS_BUILDTIME_NUMBER}" ;fi)
> +
>  
>  # fix for https://bugzilla.redhat.com/show_bug.cgi?id=1111349
>  %global _privatelibs libmawt[.]so.*
> @@ -666,6 +673,9 @@ Requires: javapackages-tools
>  Requires: tzdata-java >= 2015d
>  # libsctp.so.1 is being `dlopen`ed on demand
>  Requires: lksctp-tools
> +# there is need to depnd on exact version of nss
> +Requires: nss %{NSS_BUILDTIME_VERSION}
> +Requires: nss-softokn %{NSSSOFTOKN_BUILDTIME_VERSION}
> 
> 
> As I'm really not sure how macros are cached between srpm ops, and final rpm
> ops.



Ok. This worked. Macro is really expanded second times after the build.

I will push this to rawhide. Still the main question - whether to do this at all, remains...

(In reply to Andrew John Hughes from comment #10)
> In this case, we know NSS is part of z, but there could be other packages
> too. The reason we see a problem with NSS is because SunEC is built from a
> strange cocktail of static and linked libraries. freebl, from nss-softokn,
> is statically compiled into the provider because that's the only way the EC
> routines used are provided. However, these routines then called out to
> shared code in the NSS libraries. Thus, you get an issue like this where the
> newer freebl used by the OpenJDK build is calling out to an older set of
> shared NSS libraries.

This suggests that only a runtime requirement on nss is needed, right? Since freebl from nss-softokn is compiled in statically its not needed at runtime. If so, "Requires: nss-softokn %{NSSSOFTOKN_BUILDTIME_VERSION}" is now there incorrectly. We'd only need "Requires: nss %{NSS_BUILDTIME_VERSION}". Andrew, can you confirm?

I haven't looked at what's been added, but comment #18 looks correct; for safety, both packages should match the version they were built against as a minimum.

I think it would be a lot clearer if >= were retained in the Requires rather than the variables, but maybe that's a side-effect of how it's been generated.

> I think it would be a lot clearer if >= were retained in the Requires rather
> than the variables, but maybe that's a side-effect of how it's been
> generated.

It cant, in intial srpm rebuild, it evaluates to "". So it would be `requires: nss >= ` which is error.

In Fedora with openjdk version "1.8.0_91", only inside docker, (!) any crypto operation, ex SSLContext.getDefault() fails with

Exception in thread "main" java.lang.InternalError
        at sun.security.ec.SunEC.initialize(Native Method)
        at sun.security.ec.SunEC.access$000(SunEC.java:49)
        at sun.security.ec.SunEC$1.run(SunEC.java:61)
        at sun.security.ec.SunEC$1.run(SunEC.java:58)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.ec.SunEC.<clinit>(SunEC.java:58)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at java.lang.Class.newInstance(Class.java:442)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
        at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
        at sun.security.jca.ProviderList.getProvider(ProviderList.java:233)
        at sun.security.jca.ProviderList.getService(ProviderList.java:331)
        at sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
        at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
        at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
        at Test.main(Test.java:12)

Workaround was to also update nss libs.  Latest openjdk 1.8.0_91 broke this

*** Bug 1332867 has been marked as a duplicate of this bug. ***

(In reply to Andy Sh from comment #26)
> In Fedora with openjdk version "1.8.0_91", only inside docker, (!) any
> crypto operation, ex SSLContext.getDefault() fails with
> 
> Exception in thread "main" java.lang.InternalError
>         at sun.security.ec.SunEC.initialize(Native Method)
>         at sun.security.ec.SunEC.access$000(SunEC.java:49)
>         at sun.security.ec.SunEC$1.run(SunEC.java:61)
>         at sun.security.ec.SunEC$1.run(SunEC.java:58)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at sun.security.ec.SunEC.<clinit>(SunEC.java:58)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
> sun.reflect.NativeConstructorAccessorImpl.
> newInstance(NativeConstructorAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.
> newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>         at java.lang.Class.newInstance(Class.java:442)
>         at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221)
>         at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at
> sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
>         at
> sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
>         at sun.security.jca.ProviderList.getProvider(ProviderList.java:233)
>         at sun.security.jca.ProviderList.getService(ProviderList.java:331)
>         at sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
>         at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
>         at javax.net.ssl.SSLContext.getDefault(SSLContext.java:96)
>         at Test.main(Test.java:12)
> 
> Workaround was to also update nss libs.  Latest openjdk 1.8.0_91 broke this

See https://bugzilla.redhat.com/show_bug.cgi?id=1332867#c5

How will the fix to this issue change, if 
Requires nss >= XXX wil change to 
Recommends nss >= XXX wil change to 

It will update if possible, but not break system when the requested NSS is still in testing repo. However, is it then fix?

Pushed (with requires) to f24 and will go also to f23:
http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/commit/?h=f24&id=e6c8770ea07cdec900b704be8752ee40f6afe9f2
http://koji.fedoraproject.org/koji/taskinfo?taskID=14011344

(In reply to jiri vanek from comment #29)
> How will the fix to this issue change, if 
> Requires nss >= XXX wil change to 
> Recommends nss >= XXX wil change to 
> 
> It will update if possible, but not break system when the requested NSS is
> still in testing repo. However, is it then fix?

It will break when installed via RPM, AFAIK.

The scenario of the built-against version of NSS (or any version greater than it) not hitting stable while that version of openjdk hitting stable seems the more unlikely case than somebody installing via RPM directly. Note that this case should even get caught via Taskotron[1][2]. Formerly AutoQA.

I'd vote for keeping it with Requires.

[1] https://fedoraproject.org/wiki/Taskotron
[2] https://fedoraproject.org/wiki/Taskotron/Tasks/depcheck

It should be Requires. If the version of NSS it was built against is unavailable, then not installing the new version of OpenJDK is the correct behaviour.

java-1.8.0-openjdk-1.8.0.91-5.b14.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6747aa8f70

java-1.8.0-openjdk-1.8.0.91-5.b14.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ae0ad53b2

java-1.8.0-openjdk-1.8.0.91-5.b14.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6747aa8f70

java-1.8.0-openjdk-1.8.0.91-5.b14.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ae0ad53b2

java-1.8.0-openjdk-1.8.0.91-5.b14.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

java-1.8.0-openjdk-1.8.0.91-5.b14.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.