Improve the way rpm decides what is newer

Jesse Keating jkeating at j2solutions.net
Sat Nov 21 15:26:23 UTC 2009



On Nov 21, 2009, at 3:00, Michael Schwendt <mschwendt at gmail.com> wrote:

> On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
>
>> We should just use release epochs, people might hate them for  
>> whatever
>> reasons, but they would easily prevent such issues from happing.
>
> Vendor Epochs have been discussed years ago and have been rejected.
> The normal %{epoch} in RPM Version Comparison is hidden and bad enough
> already. We don't need another hidden "super-Epoch" that wins
> version comparison even with that other %epoch.
>
> There are times when you can push updates to current/old stable  
> releases
> but not newer/latest releases. E.g. temporary breakage of build  
> requirements
> or the buildsys target. All that's needed is an automated check,  
> such as
> the old upgradepathcheck script. Plus to put this onto the release  
> criteria
> list of items to check prior to a new final release of a dist as  
> well as
> when pushing updates. Violated upgrade paths should trigger an alarm  
> bell.

That's planned as part of the build acceptance autoqa tests.

--
Jes




More information about the devel mailing list