Proposal - "Slow updates" repo

[Kevin Kofler]

Seth Vidal wrote:
> you mean like the already existing yum security plugin and the update info
> that bodhi generates?

Except it just doesn't work... 2 big problems there:
1. Security updates can be obsoleted by non-security updates. So if you
didn't install the security update in time, you'll never get it.
2. Sometimes security updates cause regressions. Usually these are fixed
very quickly... in a regular bugfix update. With the result that users of
yum-security will be stuck with the regression (or if they didn't update in
time, with situation 1., i.e. without the security update).

To solve 2., fixes for regressions from security updates would have to be
marked security as well, or (probably better) use a new category ("bugfix
for security update") which is also pulled in by yum-security.

To solve 1., the metadata would have to carry the information for the
security update even after it is obsoleted, and yum-security would have to
understand that if foo-1.2.3 is a security update, the currently installed
package is foo-1.2.2 and the current version in the repo is the bugfix
update foo-1.2.4, it should install foo-1.2.4. Or alternatively, the latest
security (or "bugfix for security", see above) update would have to be
carried in the repos in addition to the latest overall.

In its current state, yum-security is very unreliable and outright
dangerous.

An additional issue is that updates are rarely tested in isolation. Usually,
packagers and testers are up to date with all their packages. And it
happens quite a few times that an update to one package uncovers a bug in
another package, which is then (or ideally, at the same time, using a
grouped update) fixed by an update to that other package. (For example, K3b
crashed after a KDE 3.4->3.5 upgrade and needed to be updated, likewise for
KTorrent and KDE 4.0->4.1. KDE upgrades are normally backwards-compatible
(and thus the soname mechanism won't drag in application updates), but
sometimes they trigger bugs in individual applications. But there are many
examples of this problem outside of KDE as well.) This is why all RHL
updates used to carry the following notice:
> Before applying this update, make sure all previously released errata
> relevant to your system have been applied.
which is still sound advice.

        Kevin Kofler