Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> writes: > There are currently separate updates for nss 3.33.0 and nspr 4.17.0 in > both Fedora 26 and 27. However, nss 3.33.0 requires nspr 4.17.0. > > As a reminder, this is a violation of the Updates Policy: > > https://fedoraproject.org/wiki/Updates_Policy#Updating_inter-dependent_packages > > "When one updated package requires another (or more than one other), > the packages should be submitted together as a single update." > > The problem with doing things this way is that, if the nss update > happened to be pushed stable before the nspr update (which could easily > happen due to human error, network issues etc. even if the maintainer > *intends* to push them together!), the dependencies in the stable > repository will be broken; nss will not be installable. Thank you for the reminder; there was indeed a fuss in updating nspr/nss this time. I have submitted the nss updates for F27/F26 stable, after nspr 4.17 got pushed to stable. > On Fri, 2017-10-13 at 10:38 -0700, Josh Stone wrote: >> On 10/12/2017 05:34 PM, Adam Williamson wrote: >> > In this case there's an even worse consequence; if you do attempt to >> > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the >> > nss packages (as it notices that they are missing dependencies), but it >> > *will* install nss-softokn-freebl . With this mix of packages (most of >> > nss at 3.32.0, but nss-softokn-freebl at 3.33.0), nss and anything that >> > depends on it just fails to work at all - e.g. curl and dnf...so that's >> > an extremely bad outcome. >> >> Then isn't this a packaging bug? They currently use ">=" requirements, >> but if a greater version doesn't work, shouldn't they be "="? > > Well, there's *additionally* probably a packaging bug, yeah: nss- > softokn-freebl should be more strictly tied to the other packages. I still don't figure out why this causes a problem. nss-softokn-freebl is parallel installable with older nss* packages and that could run into a problem if nss-softokn-freebl used a new symbol from a newer nspr. However, as far as I know nspr 4.17 doesn't add any new symbol so it's shouldn't be a problem at least in this case. Regards, -- Daiki Ueno _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx