SELinux RPM scriplet issue annoucement

[Reindl Harald]

Am 19.01.2014 20:48, schrieb Michael Schwendt:
> 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? ;)

i know, in a perfect world it does not happen

> 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.

in that case - no

testers also hardly had realized the responsible package
said from one running updates-testing and often koji over years on my machines

> It simply won't work well, if testing is a race for the fastest +1 votes

depends on the "test matrix" and package

> 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?

most likely

> The nfs-utils update has been pushed to stable with +3 one day after the bad selinux policy.

which says not much

most of my servers have selinux completly disabled

so the selinux policy can be as broken as possible but that does not
mean that i can't qualify a qt, kde, samba or whatever package which
works as expected in my workloads

>> 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?

because i faced too much packages in updates-testing at all 3 days after
build that hardly broken or not installable at all where i honestly ask
"has the packager ever instaleld it on one of his systems"

> 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.

for that package yes

on the other hand there are enough small bugs where it is even hard
to realize what package / library is really responsible and library
updates with a complete reboot and some hours qualify at least

"there is not more broken then before and in the best case it fixes
issues for others or at least does not more harm then before"

> 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

that is what i am doing always before give karma:

* rebuild one of my self maintained packages
* they all get YYYYMMDD in the %release automatically
* run a yum update and verify YUM/RPM works

> 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

expect that testers are using only yum for several reasons and many
of them even uninstalled all that graphical package stuff if possible
by cross-dependencies, that won't change in the future as long nobody
takes away the CLI completly which drives away that users completly

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140119/3225c878/attachment.sig>