On Wed, 2008-12-10 at 15:03 -0600, Les Mikesell wrote: > Perhaps I haven't thought it all the way through, but I'd expect most of > this to take care of itself via the age factor with the updater ignoring > anything that doesn't meet the selection criteria on a package or any > dependencies. As long as everything works, you'd just be able to get > the same update the bleeding-edge machines got 2 weeks (or...?) ago. The > only tricky part would be how to push expedited fixes ahead of the clock > because they might drag along massive dependencies, but that should only > be done in rare carefully-consdered cases anyway. Negative feedback > could just slow the clock down. > > But, feel free to start from scratch on a working design that gives > control to the end user. I can't help thinking that a > version-controlled (git/subversion) package list with tags to give > snapshots-in-time would be the ultimate way to do it. That could > divorce the tool making the 'risk-factor' decisions from yum itself. > You might build a new set of tags daily, recomputing the package lists > that should appear in each level of risk and yum would work with the > list instead of the repo contents. That would introduce a new workload > for the mirrors, though. > > One other consideration a new package management scheme needs to turn > this into reproducible updates is to remember the repo where each > package lives (and understand that you don't know them all ahead of > time...). > The problem here is that these are descreet commits that one can pull or cherry pick at will and integrate them into whatever current repo view you have. It's far more complicated than that with interdependencies and upgrade paths to consider. Please re-read my scenarios and try to come up with any possible way to make it work. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
