#464 Fix nss update issues
Closed None Opened 9 years ago by kevin.

= Proposal topic =

Fix the nss family of packages so they stop causing update issues.

= Overview =

The nss family of packages continue to cause issues for Fedora users. (This includes, nss, nss-softokn, nspr, etc).

= Problem space =

  • nss packages require a buildroot override. This means sometimes things get built and need the new version before it's pushed.
  • nss packages have a very strict interdependence. If they aren't all correctly updated for new versions there are broken dependencies.
  • nss packages seem to me to update quite often. Restricting stable updates to security fixes only might be a good idea.
  • nss packages seem to have a complex multilib footprint, resulting in changes causing the packages to be multilib, then not, then again. This should be fixed.

= Solution Overview =

We should look at any/all of the following:
add co-maintainers to help with updates.
fix packaging to be less fragile
* document updates process or come up with a better workflow for updates.

= Active Ingredients =

nss package maintainers, fesco, folks who wish to be co-maintainers, experenced packagers that can help with packaging.

= Owners =

I will for now.

= Additional notes =

This ticket is NOT about placing any blame on anyone. It's about making this better.
There is currently an issue with nss holding back a firefox update for f12/f13. We should work asap on fixing this so the security update can go out, then look at longer term fixes.

So the precise issues that exist here seem to be a bit muddy. Here's what I've pieced together from som IRC conversations:

  • Broken deps. When nss rebuilds, deps become broken. It has been speculated that this is not due to nss being unable to maintain a stable ABI for 13 months but instead that the nss buildroot overrides are causing packages to be built against an nss that is not yet available when those updates are pushed to stable.
  • firefox being broken by nss updates or lack thereof. The speculation here is that firefox needs newer features of nss/nspr than are available in the old packages. Therefore, firefox needs to be built against newer versions of the package than are in the stable updates repo more frequently than most packages.
  • Why are there broken deps from things coming from the same tarball? We have three separate source packages for the same tarball which allows this mismatch to occur. Why not two? Or one (like most other packages)?
  • Why do new nss packages require a buildroot override? Is this just a misunderstanding about how building packages works in koji?

If most of these problems really do stem from buildroot overrides... maybe we need to dedicate some koji build tags to building new nss versions in. Then the collection of packages that require each other can be built there and the whole thing pushed into testing (and then stable) together. If the API stays backwards compatible and it's just a small portion of packages that need the newest nss releases to build, that seems like it would be managable.

The broken dependencies where caused by some ill-conceived "shortcuts" in the .spec file. As requested, I'm documenting the nss update process with advise to the package maintainer. See

Note that this page is now at:

I think thats a great checklist for updating with the current packaging, but we should look at it and see if we can simplify it.

emaldonado: Can you address the questions in comment 1?

Removing meeting keyword for now.

Elio: Can you perhaps answer the questions in comment 1?
We can see about moving this forward and getting things happy...

The Updating_NSS page is a great idea and I think it's already helped, but perhaps we can also get the package(s) to be simpler and help that way too.

My answers to the questions posed in comment 1:

  • Broken deps. Yes, nss has maintained a stable ABI. It is indeed one of the nss' guarantees and the track record has been good for many years and conyunes to be. The nss buildroot overrides have caused packages, mostly mozilla pacakges, to be built against an nss that is not yet available when those updates are pushed to stable. The are many updates, particualrly upstase of the higher levels of nss that don't require softokn or util to be updated, that proceed without problems and nobody notices. Thye mostly fedora packages. The problem has ocurred when doing major updates or rebases where we mus update all three packages, namely: nss-util + nss-softokn + nss and the mozilla prroducts need updating such as when we have security driven updates.

  • firefox being broken by nss updates or lack thereof. I intend to coordinate more closely with the Mozilla packagers the to avoild such problems. In Bodhi we should submit xulrunner (FF and Tbird) together with teh nss pcakages as one bundle to avoiv the mozilla packages goind out to stable ahead of nss. This would be necessary in particualr when doing security-driven updates. When bundiling is not possible we sghould be very proactive getting proven testers to give (or deny) karma so the nss/softoken/util don't linger to long as stable candidates.

  • We have three separate source packages for the same tarball which allows this mismatch to occur. Why not two? Or one (like most other packages)? The spitting off of softoken as a stand-alone package is motivated by FIPS-140 validation. the nss-softoken pacakge contains the softoken and freebl libraries wich constitute the module cryptographic boundart, to use NIST FIPS terminology, and this is what is really validated not teh entire nss. This is of importance for RHEL and not for Fedora I must concede. There is a great maintainance value to having the RHEL packaging not diverge from Fedora's. At one time I experimented with having one big monolythic spec file with many subpackages but that didn't solve our problems so I had to opt for the drastic split. Even though upstream ships one big tar ball there has been consideration of splliting thins as well.

  • The nss packages require a buildroot override because on stable branches we don't have teh concenience of chain build as we do on Rawhide.

  • Many of problems really stem from buildroot overrides but they mainly stem from ignorance on the part of the new package maintaner, that would be me, who was learning the trade as he went along and should have asked for more advise from those in the know.

The idea of a special tag (like it's used for KDE) may be worth considering, not sure such a drastic measure is needed and what other complication would it entail. I would like to learn more about it.

Last modified 2 years ago. As far as I can tell, NSS updates breaking things are at least much decreased. I can't recall them breaking anything more frequently than any other kind of update.

Either way, this can get closed out.

Login to comment on this ticket.