SELinux RPM scriplet issue annoucement
mschwendt at gmail.com
Sun Jan 19 19:48:44 UTC 2014
On Sun, 19 Jan 2014 20:03:14 +0100, Reindl Harald wrote:
> this case is *very* special because you also need to realize *what*
> update before breaks the scriptlets and that it break all scriptlets
> zero chance to figure that out for 99 out of 100 users
> you only need to look at the amount of reports that other packages
> seems to be broken to get the picture
True. However, it's not the Fedora product's users who do the testing, but
brave testers with updates-testing enabled, who evaluate packages _before_
they get pushed into the stable updates repo.
All the "ordinary" users, who thought that the nfs-utils update contained
a bad scriptlet, assumed that such a bug has slipped through the Fedora
testing process. What does that tell about quality of Fedora testing? ;)
Other users have reported the same issue for "initscripts" and other
packages. What these people have in common is that they have noticed the
scriptlet errors and have opened a ticket in bugzilla. IMO, testers would
have noticed it too, if the test update had been offered in the
updates-testing repo for a longer time. It simply won't work well, if
testing is a race for the fastest +1 votes.
I wonder what a tester would have done when encountering a scriptlet
error, if the bad selinux package had not been marked stable yet? Would
it have led to a -1 on the wrong package? The nfs-utils update has been
pushed to stable with +3 one day after the bad selinux policy.
> that case seems to be unavoidable without force every packager of
> critical path updates to test them manually before they appear in
> updates-testing and on bodhi at all and to catch the specific case
> push the updates to testing after at least on their machine a
> independent update was applied without problems - unlikely to happen
Why that? Why the manual installation?
There is no need to rush when voting in bodhi. Such a selinux policy
update with many changes is _scary_. Come on, Fedora 20 has been released
already after a long development/testing cycle. Why take the risk of
breaking it with large updates that are rushed out? Where the released
product is broken already since day zero, a few more days of testing the
fixes don't hurt.
One of the fundamental actions that "critical path package" updates must
be able to complete is """get updates""". That means that after a full
"yum -y update" to fetch a latest batch of Test Updates, the tester must
attempt at triggering further system updates. A downgrade of some packages
may be enough to test a subsequent manual "yum update", at least.
Alternatively, wait for the next updates/test-updates to appear in the
repos, but what about automatic updates and update notifications?.
Good, if Yum still works, at least. But that doesn't mean testers should
neglect the graphical package tools and system update mechanisms many
other users will depend on.
More information about the devel