Hi Seth et al. I noted that the rpms on all the mirror site have common timestamps, and it is this timestamp that I want to use. (Thank you Rsync).
I am sorry to say, but the application that has caused me the most grief in the past with corruption and hours of recovery time was YUM. The second was the SQL package, and the third, was rpm itself. When it was the kernel, I just changed the menu.lst to point to the previous kernel. Currently the application that is not showing bugs in testing is Compiz and Beryl. It causes Gnome corruption problems on my system. I have raised bugzilla reports for same, but the damage has been done to some home directory entries. If there is a better way, please advise. Leslie From: seth vidal <[EMAIL PROTECTED]> To: yum development <[email protected]> Date: Tue, 06 Nov 2007 13:52:16 +0000 Subject: Re: [Yum-devel] How does one go about requesting new features? On Tue, 2007-11-06 at 05:38 -0800, Leslie Satenstein wrote: > Subject line says it all. > > I would like a bleeding death type of protection option. For a select > group of packages or modules, I would like to delay by XX days, it's > upgrade or implementation. > > I have thought about how to do it and came up with this idea. > > yum.conf file accepts an exclude parameter. > > Could a sub parameter be included as follows: > > exclude --delaydays=(xx,module1,module2,module2) othermodule1 > othermodule2 > > The comparison for days would use the mtime of the rpm package. > > Why the delay? > > To often, a fix goes out to the community for a critical module, > critical to the end-user. > > It gets installed that same day, and then individuals find out that > the fix is defective, and hence, they need to recover. Not everyone > uses rpm's recovery facility. > > By delaying xx days, one can allow others to discover the bug, my > system was not damaged. > > Rationale: In the xx days following the release of the modules listed > between parenthesis, if there was no withdraw of said module, it would > go in. If there was a fix to the fix, the latter would eventually go > in. > The hard part about doing this is finding the date to measure against. If you measure it against the date stamp on the file then you'll probably have a lot of things installed immediately b/c the file datestamp is sometimes days before it gets pushed. If you measure against the first time it showed up in the metadata (and your system saw it) then you have to keep that information somewhere on your system b/c yum doesn't have it normally. The latter is probably the option you'd want b/c it would replicate what you've listed above. In this case it would be best as a plugin b/c it is a wee bit obscure(imo) for a core feature. -sv
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
