> 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 That is very sane to me > 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 thats now part of the version that is not a good thing the version should always match upstream > 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). It will work the way you describe the dist tag ensures that an upgrade from fc4 to fc5 will work as expected by updating the package 2.3.5-1.fc5 is higher than 2.3.5-1.fc4 why because of the 4 and 5 at the end. > 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). Ok lets look at the logic here 2.3.4-3.fc3 2.3.4-1.fc4 yum and rpm look at the above two senarios and say the 2.3.4-3.fc3 is higher than 2.3.4-1.fc4 because of simple math 3.x is higher than 1.x rpm and yum do not understand disttags they are a macro we use to differenciate between the releases. it makes sense to us to go oh fc4 is higher than fc3 but we are mathmeticly doing the comparison > 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. > add a .x etc to the end is is the least significant bit If you build a package with a disttag outside of the buildsys or mock you will have an empty tag it will not be there. Dennis -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
