Why do we need FC version attached to the package name?

Jesse Keating jkeating at j2solutions.net
Mon Jun 22 14:35:52 UTC 2009



On Jun 22, 2009, at 12:01, Michael Schwendt <mschwendt at gmail.com> wrote:

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

Releng and qa are interested in finding and fixing these issues.  
Upgrade path issues will be a part of the autoqa system.

--
Jes




More information about the fedora-devel-list mailing list