On Fri, 2011-07-29 at 02:29 +0300, Kalev Lember wrote: > On 07/28/2011 08:48 PM, Dennis Gilmore wrote: > > On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote: > >> I thought there was a hard rule about not having nvrs go backwards, and > >> if a bad build was put out, it should be fixed with epoch or other such > >> NVR things to make sure the upgrade path continues. (that is once a > >> build makes it out in the nightly repos) > > > > I untagged the rpm build and we do have that rule, I could have sworn that it > > had only been built that day and not made it into rawhide. if i had realised > > that it had made it to rawhide i would have bumped the epoch on the old build > > to ensure that updating was correctly handled. > > Bumping epoch in rpm would have made it harder for all other packages to > depend on a particular rpm version. Instead of having e.g. > Requires: rpm >= 4.9.1, they would now also have to remember the put the > correct epoch in there. > > I think it's reasonable to have a broken package pulled from rawhide for > a little while, if it's going to be properly fixed up in a few days. > Yes, we should try to avoid such things, but having a hard rule here > would be counter-productive. > > Also, we have a much worse case of versions going backwards. After each > Alpha release, lots of people are going to install Branched pre-releases > and they automatically get enabled updates-testing repos. And in that > updates-testing repo, packages are often pulled out and versions go > backwards. Why is such practice allowed in Branched, but not in rawhide? Indeed; and remember we have yum distro-sync which fixes that problem quite nicely, I don't see why it shouldn't also work for quick reverts in Rawhide. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
