Package EVR problems in Fedora 2008-07-26

[Kevin Kofler]

Stephen Warren <s-t-rhbugzilla <at> wwwdotorg.org> writes:
> That's a great argument for not bumping package version (rather than 
> release) too much!:

Sorry, that's not how Fedora works. Fedora is not Debian stable nor RHEL. 
Version upgrades are the norm rather than the exception.

> 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.

And that makes sense, as Rawhide has no updates repository and it's where new 
stuff should get tested first anyway.

> 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,

This is your opinion, but it does NOT reflect current Fedora practices and 
policies, and I'm very strongly opposed to making that a policy, ever.

The policy which the upgrade path script is enforcing is that a version bump in 
an F9 update will have to also be pushed to F10 updates.

> 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.

You're missing several reasons for a version bump:
* security fixes: Fedora explicitly encourages upgrading rather than 
backporting to fix security issues.
* upstream bugfix releases, which can fix bugs experienced by Fedora users 
(including security bugs, see above)
* upgrades required to keep a client working with current servers: We've had 
that situation quite often with IM clients.

Some maintainers also like pushing updates for new hardware support and/or new 
features even to older releases. That practice may be up for debate (I 
personally don't think it's a bad thing unless this happens when the release is 
almost EOL and/or introduces breakage), but the other 3 reasons I have given 
apply to old releases just as much as to new ones.

> 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.

Yet this is the status quo and works just good enough for us. In fact the first 
real breakage due to this issue that I know of has been sighted very recently 
with F8 Python and F9 OpenSSL not being compatible, preventing the final yum 
update. It has been fixed by pushing new Python and Python-urlgrabber to F8 
which make yum work with no working OpenSSL.

But this is really an argument for online upgrades or upgrades with the updates 
repository enabled, not an argument for making Fedora no longer Fedora.

         Kevin Kofler