Description of problem: It seems nss-sysinit is intended to be enabled by default in recent Fedora version, and it is enabled in F13 after install. It is, however, disabled after first nss-sysinit package upgrade. This problem is caused by incorrect rpm %pre / %post scripts. Package calls 'setup-nsssysinit.sh on' in postinstall and 'setup-nsssysinit.sh off' in preuninstall. They are run unconditionally, and given the order in which rpm scripts are executed (%pre %post %preun %postun), nss-sysinit end up being disabled after the first package upgrade. If the intention is to have it enabled by default, 'setup-nsssysinit.sh off' should only be run on package erase. This is similar to what's commonly done with initscripts / chkconfig, see e.g.: http://fedoraproject.org/wiki/Packaging/Guidelines#Scriptlets Version-Release number of selected component (if applicable): nss-3.12.7-6.fc13
Even if we ran setup-nsssyinit off on package erase only, say with a guard such as %preun sysinit if [ $1 -eq 0 ] ; then %{_bindir}/setup-nsssysinit.sh off fi we would still have the problem on the first update. The erase is handled by the faulty scriptlet of the prior version of nss.spc still in the system at the cleanup phase and that will turn it off. Subsequent updates will be okay. Come to think about it, $1 can never be 0. Since 3.12.5 nss-sysinit is required by nss and can't never be removed entirely, otherwise nss would be totally erased as well with dire consequences. The proper long term solution is to change system-pkcs11.txt to have nsssysinit on and get rid of the {post|prein} sysinit scriptlets altogether. We must solve problem where the old scriptlet turned sysinit off. A %posttrans sysinit scriplet will allow us to undo the effects turning off done by the old scriplet. On a subsequent update we get rid of this '%posttrans sysinit' as well.
Created attachment 450012 [details] Fix the disabling of nss-sysinit on update Change of system-pkcs11.txt would be permanent whereas the use of %posttrans scriptlet would be transitional.
Comment on attachment 450012 [details] Fix the disabling of nss-sysinit on update r+ You know this also turns off the user's preference of turning sysinit off...
Yeah, I realized the same thing Bob mentions above. With current rpm scripts, sysinit gets disabled on each upgrade. With new, it get enabled on each upgrade. Both cases ignore user preference.
The new way is the lesser of two evils as it upsets the less number of people but ignoring user's preferences isn't good. The problem is that there is no way to tell whether sysinit was disabled because the user wanted it or because the old faulty scriplet turned it off. Any ideas?
Right, if you assume that at the time you try to upgrade to fixed packages it can be disabled because of previous upgrade or admin decision, there's unlikely to be a good way to tell which case it is. Thinking a bit more about this, what about versioned %triggerpostun, that would only re-enable once, when first upgrading from affected version. Assuming this is first fixed in nss-3.12.7-10.fcX, this may work: %triggerpostun -n nss-sysinit -- nss-sysinit < 3.12.7-10 /usr/bin/setup-nsssysinit.sh on
nss-3.12.7-8.fc14,nss-softokn-3.12.7-7.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.7-8.fc14,nss-softokn-3.12.7-7.fc14
nss-3.12.7-8.fc13,nss-softokn-3.12.7-7.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/nss-3.12.7-8.fc13,nss-softokn-3.12.7-7.fc13
nss-3.12.7-8.fc14, nss-softokn-3.12.7-7.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss nss-softokn'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.7-8.fc14,nss-softokn-3.12.7-7.fc14
Elio, I believe you want to use nss-sysinit < 3.12.7-8 trigger on F13/F14 and not the same < 3.12.8-3 as in Rawhide, where nss is already updated to 3.12.8.
oops, poor cherry-picking when merging.
%triggerpostun -n nss-sysinit -- nss-sysinit < 3.12.7-9 as I have to bump the release number
nss-3.12.7-9.fc14, nss-softokn-3.12.7-7.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss nss-softokn'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nss-3.12.7-9.fc14,nss-softokn-3.12.7-7.fc14
nss-3.12.8-2.fc14,nss-softokn-3.12.8-1.fc14,nss-util-3.12.8-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.8-2.fc14,nss-softokn-3.12.8-1.fc14,nss-util-3.12.8-1.fc14
nss-util-3.12.8-1.fc12,nss-softokn-3.12.8-1.fc12,nss-3.12.8-2.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/nss-util-3.12.8-1.fc12,nss-softokn-3.12.8-1.fc12,nss-3.12.8-2.fc12
nss-3.12.8-2.fc13, nss-softokn-3.12.8-1.fc13, nss-util-3.12.8-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.12.8-2.fc14, nss-softokn-3.12.8-1.fc14, nss-util-3.12.8-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
nss-util-3.12.8-1.fc12, nss-softokn-3.12.8-1.fc12, nss-3.12.8-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.