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 host
> > 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 2.6.
>
> 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 sucks
about Fedora".
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 mailed
package owners directly. That helped with getting upgrade problems
fixed, but it wasn't part of any release policy to make sure all upgrade
path violations would have to get fixed.
Then with the switch to koji+bodhi a few package owners complained loudly
about false positives that were caused by pending builds, which were not
found in the master repo yet. A few other package owners jumped upon the
train and questioned the usefulness of the script, since they were of the
opinion that breaking upgrade paths the way they did it with updates-testing
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 regularly,
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 would
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 without
updates-testing. There are still packagers who bump %version or %release
in old dist updates without considering the consequences with regard to
dist upgrades. And in Rawhide? Just because a packager doesn't track
Rawhide for some time should not imply that files in "devel" cvs become
older than in the other dist branches or that updates for released dists
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 update has
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
