On Sun, 21 Jun 2009 19:08:11 -0400, Dave wrote:
On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote:
I *wish* it made a difference. I did an upgrade am an left with a
of fc10 packages because the fc11 ones weren't considered newer.
For example people with updates-testing enabled on fc10 got a
non-upgraded yum because the versions were the same (except for
fc10/fc11) and it stopped working because python went from 2.5 to
That's messed up. We used to check just before release time that this
situation never occured.
No, that's not entirely true. The full story is from the book "What
There used to be regular runs of the upgradecheck.py script from the
Fedora Extras era, which mailed the fedora-maintainers list (and later
fedora-devel list), and later the upgradecheckspam.py script which
package owners directly. That helped with getting upgrade problems
fixed, but it wasn't part of any release policy to make sure all
path violations would have to get fixed.
Then with the switch to koji+bodhi a few package owners complained
about false positives that were caused by pending builds, which were
found in the master repo yet. A few other package owners jumped upon
train and questioned the usefulness of the script, since they were
opinion that breaking upgrade paths the way they did it with updates-
and stable updates would not be considered a problem.
Even later there used to be another script that queried koji for more
accurate package release versions, but it has never been run
not even prior to the next Fedora release.
It should probably be added to the rel-eng
release checklist if it isn't there already.
Does rel-eng have any interest at all in avoiding some upgrade path
problems? I don't see that. Running a script to catch _some_ issues
be tons better than not running a script at all. The problem is not
limited to some people upgrading from F10 updates-testing to F11
updates-testing. There are still packagers who bump %version or
in old dist updates without considering the consequences with regard
dist upgrades. And in Rawhide? Just because a packager doesn't track
Rawhide for some time should not imply that files in "devel" cvs
older than in the other dist branches or that updates for released
get ahead of builds in Rawhide. The freeze only adds to the problem,
because packagers can push upgrades for old dists while the unreleased
dists remains frozen. It's also simply a crap decision if packagers
quickly mark F10 updates as stable while the corresponding F11
not seen any testing at all (while it's stuck in the growing list of
pending updates in bodhi or waiting for release of F11).
fedora-devel-list mailing list
fedora-devel-list redhat com