On Wed, 28 Jun 2006, Ville Skyttä wrote:
> [lots of broken upgrade paths]
> Sadly, it seems that this whine mail hasn't helped noticeably to kick
> folks to fix up their packages' upgrade paths, especially between FC-5
> and devel. I've filed bugs about a bunch of others cases, and most of
> them have been fixed, but more breakage is introduced all the time.
Since ville and me were discussing this on bugzilla's item on a package
I maintain that had such an issue, let's talk about it here instead.
See previous discussion:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193623
Ville suggested using the following
3: 0:2.3.4-3.fc3.2
4: 0:2.3.4-3.fc4.1
5: 0:2.3.4-3.fc5.1
6: 0:2.3.4-3.fc6
Now to mee this seems like a bad hack. If I fix a bug in FC4, for version
2.3.4-3, then it should have the version number of 2.3.4-4.fc4 and not
2.3.4-3.fc4.2. This just introduces yet another versioning number. If
we need to fix upgrade paths by making things obvious, we should pull the
disttag more to left, eg:
3: 0:2.3.4.fc3-2
4: 0:2.3.4.fc4-1
5: 0:2.3.4.fc5-1
6: 0:2.3.4.fc6-3
Additionally, what happens if all distros are now upgrade, so they are all
version 2.3.5-1, and the user upgrades from fc3 to fc4? Shouldn't it replace
the identical version with the package from the newer distribution, instead
of leaving the old package there? What if some dependancy changed, so the
fc3 version cannot work but the fc4 version with the same version number
does work (eg nptl vs no nptl or whatever).
Personally, I think an upgrade using anaconda/yum should have the additional
logic to do the right thing, and even go from 2.3.4-3.fc3 to 2.3.4-1.fc4
during an upgrade, if that is what is available, and only leave old dist
versions of software that is not available in the new dist version (and not
Obsoleted: by some other package in the new dist).
Apart from this issue, most of my "more fixes in older distributions" were
due to make tag breaking halfway through, with as only fix to bump the version.
Fixing that problem once and for all would probably greatly reduce the amount
of these upgrade path issues.
Paul
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
