Broken upgrade paths discussion

[Dennis Gilmore]

> 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