Package Management Blows Goats (use cases)

[seth vidal]

On Mon, 2007-08-13 at 20:46 +0200, Nicolas Mailhot wrote:
> BTW, on the same topic. Another reason our package management sucks is
> its propagation time. Builds are composed in koji. Then after a while
> propagated to a master serveur. Then after some hours or days synced by
> several layers of mirrors. Then at last installed on user systems. So
> you have this huge delay between packager action and package
> propagation.
> 
> In particular that means when a faulty package is released (cough
> rawhide cough) it continues to be installed by users hours or days after
> the packager has identified there's a problem and started to work on a
> fix. Meanwhile users flood the support channels with the same questions
> (or not, since so many people hit the same problems they just hope
> someone else already reported them and keep quiet)
> 
> Since everyone feeding from the same instantaneously-updated root server
> won't happen, the next best thing would be not to add a wiki with info
> on known problems (difficult to keep up to date and no one will read it
> before hitting problems anyway), but rss-like blacklist support in yum.
> (just a signed known-bad package list in a central location yum would
> consult before considering new packages)
> 
> PROs :
> - such a list can be updated in real-time with little effort (just put a
> FAS-protected webform somewhere before the blacklist generator)
> - such a list would be small, so there's no reasons user yums can not
> consult it directly instead of going through the big-latency mirror
> hierarchy (additionnally I'm sure the people counting fedora users would
> like this)
> - blacklisting bad packages gives packagers some time to fix problems
> - blacklisting bad packages means support channels are not flooded with
> the same repeated questions
> - working real-time blacklisting means testers know that if they hit a
> problem it's probably not been reported yet, so doing it is helpful to
> the project
> 
> CONS
> I don't see any

cons:
 - that single location is a SPOF and a bandwidth/access nightmare
 - this is just a bandaid to fixing qa problems in any of our releases.

-sv