RPM version goes backward in Rawhide

[Adam Williamson]

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