Package Management Blows Goats (use cases)

[Nicolas Mailhot]

Le lundi 13 août 2007 à 14:49 -0400, seth vidal a écrit :
> On Mon, 2007-08-13 at 20:46 +0200, Nicolas Mailhot wrote:
>  
> > CONS
> > I don't see any
> 
> cons:
>  - that single location is a SPOF 

1. It's only a SPOF if yum blocks/fails on blacklist acquisition
failure, which may not be the smartest policy

2. It's only a SPOF if the list is in a single location. There's no
reason the file can not be replicated, and it's easier to
replicate/propagate quickly a small file than the whole state of a huge
package repository

> and a bandwidth/access nightmare

3. see 2.

4. RSS feeds on busy sites show everyday it can be done. We're talking
about a small file there

5. the risk of getting a bad package which has already been fixed is a
huge reason users spurn second and third-tier mirrors and overload
high-sync-rate first-tier mirrors. 

6. when a bad package is propagated users flock to the root
infrastructure. See McLasen's recent message. What if the problem
package had been glibc instead and users had all been directed to
download the fix directly from koji instead?

>  - this is just a bandaid to fixing qa problems in any of our releases.

7. We manage many repositories were bad packages are expected to happen
regularly (testing, rawhide). Having many users hit the same problem is
not helping QA, quite the contrary:
- when many testers hit an already reported problem they feel they're
wasting their time and stop testing
- you have support burnout
- you have bugzilla flooding
- when everyone is struggling against the same high-profile problem in a
testing repo less proeminent problems are left unreported

8. A blacklist is like an airbag. You don't expect to use it, but
dispensing with it is stupid

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070813/8cc207f2/attachment.sig>