What Fedora makes sucking for me - or why I am NOT Fedora

Jeff Spaleta jspaleta at gmail.com
Tue Dec 9 22:43:08 UTC 2008


On Tue, Dec 9, 2008 at 12:50 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> It could be as simple as batching updates: suppose everything but critical
> security fixes and corrections for known-bad updates only updated every few
> weeks, and the user could could choose (with a permanent option) whether any
> particular machine should update on the leading or trailing edge of this
> window.

1) Couldn't you get most of what you want by having a yum plugin that
deliberately held back updates which were too new for your local
administration needs? if package build/release datestamps were
available in the repository metadata? We already have the security and
bugfix flags in the metadata.

2) 'known bad' assumes we actually know that updates are bad before we
release them. If we knew they were bad we wouldn't release them at
all.


>
> Or, pick a time frame reasonable both for mirrors to hold updates and for
> users to complete testing (2 months?) and only remove packages after their
> replacements have reached that age.
>
> Or, what if one machine's yum automatically acted as a proxy for another's
> update, perhaps with an error generated if the package hadn't been
> downloaded already and if you want to be even more helpful, a warning if
> none of the code from a package had been run on the intermediate machine?

Feel free to take over InstantMirror and extend it
https://fedorahosted.org/InstantMirror/

-jef




More information about the fedora-devel-list mailing list