Package EVR problems in Fedora 2008-07-26

Stephen Warren s-t-rhbugzilla at wwwdotorg.org
Sun Jul 27 04:40:44 UTC 2008


Kevin Kofler wrote:
>Stephen Warren <s-t-rhbugzilla <at> wwwdotorg.org> writes:
>>To put a fix in F8, you version it pkg-1.fc8.1 *not* pkg-2.fc8.
> 
> That doesn't work if it's a new version.

That's a great argument for not bumping package version (rather than 
release) too much!:

In F9 before F10 final is frozen, any package version bumps must be 
reflected in rawhide/F10 too (by current policy in the existing EVR 
script, ignoring strange stuff like epochs making the base version 
number irrelevant), so people are free to bump versions without using 
the above technique.

Only after F10 is frozen would the above technique be required, and 
prohibit verion bumps. I'd argue that by that time, it'd be good policy 
to disallow version bumps in F9 anyway, since any requirement for a 
version bump that didn't exist in the first ~5 months of a release 
doesn't exactly seem to qualify as maintenance; instead significant new 
stuff should be in the new/latest distro release.

If something like the above is not the policy, how are CD/preupgrade 
upgrades possibly going to be reliable? An upgrade would end up 
installing whatever random subset of Fn was newer than Fn-1. Whilst I 
appreciate that a "yum update" after the upgrade would solve the issue, 
that fact doesn't address what happens when running rpm scripts during 
the install against a random mix of Fn/Fn-1, nor how the system is 
supposed to sanely boot with the same random mix before the yum update.

> This technique is useful, but to prevent dist-f8-updates > dist-f9-updates 
> situations (which are true packaging errors), not dist-f8-updates > dist-f9 
> situations (which are normal). If you push a new version to F8, you have to 
> push it to F9 too, but it'll be only in dist-f9-updates, not in dist-f9. Only 
> packaging-related issues which don't affect F9 should be fixed in F8 with the 
> n%{?dist}.1 trick.




More information about the devel mailing list