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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
