[pacman-dev] vercmp / force update
we use "vercmp" to create our diffscript http://archlinux.org/~andyrtr/pkg_diff.html vercmp still reports 0.8.10a < 0.8.10 that's why we have to use force='y' in our PKGBUILDS that also appears in pkgdesc shouldn't we fix this before the release? i suggest to create a strict rule how to mark "alpha", "beta" and "rc" packages to get them detected as smaller values than the next/final and any other post-final "a" or "A" release. Andy
On 3/5/07, Andreas Radke <a.radke@arcor.de> wrote:
we use "vercmp" to create our diffscript http://archlinux.org/~andyrtr/pkg_diff.html
vercmp still reports 0.8.10a < 0.8.10
that's why we have to use force='y' in our PKGBUILDS that also appears in pkgdesc
shouldn't we fix this before the release?
Not going to happen, bugfix only period has started, and Aaron and I would consider this feature addition.
i suggest to create a strict rule how to mark "alpha", "beta" and "rc" packages to get them detected as smaller values than the next/final and any other post-final "a" or "A" release.
Here is the issue, I will try to pose a good example. 0.8.10 is the version we have installed. Along comes version 0.8.10a. Now try to tell me with certainty whether this is a newer or older version. You cannot. If a package labels their alpha releases this way, it is an older version, so we DO NOT want to upgrade. However, if this is the notation used for bugfixes, then it is a newer version and we DO want to install it. These cases tend to be the outliers, luckily. Since we rarely would put alpha/beta software in a repo, we don't have to worry about it often. In addition, most packages stick with numerical only version numbers, allowing vercmp to work correctly. Long story short- it would be a lot of work to "fix" it, and there isn't even a definite way to do that. -Dan
2007/3/5, Dan McGee <dpmcgee@gmail.com>:
On 3/5/07, Andreas Radke <a.radke@arcor.de> wrote:
we use "vercmp" to create our diffscript http://archlinux.org/~andyrtr/pkg_diff.html
vercmp still reports 0.8.10a < 0.8.10
that's why we have to use force='y' in our PKGBUILDS that also appears in pkgdesc
shouldn't we fix this before the release?
Not going to happen, bugfix only period has started, and Aaron and I would consider this feature addition.
i suggest to create a strict rule how to mark "alpha", "beta" and "rc" packages to get them detected as smaller values than the next/final and any other post-final "a" or "A" release.
Here is the issue, I will try to pose a good example.
0.8.10 is the version we have installed. Along comes version 0.8.10a. Now try to tell me with certainty whether this is a newer or older version. You cannot. If a package labels their alpha releases this way, it is an older version, so we DO NOT want to upgrade. However, if this is the notation used for bugfixes, then it is a newer version and we DO want to install it.
These cases tend to be the outliers, luckily. Since we rarely would put alpha/beta software in a repo, we don't have to worry about it often. In addition, most packages stick with numerical only version numbers, allowing vercmp to work correctly.
Long story short- it would be a lot of work to "fix" it, and there isn't even a definite way to do that.
Ehm, maybe silly question: why not compare package creation date/time? -- Roman Kyrylych (Роман Кирилич)
On 3/5/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 3/5/07, Andreas Radke <a.radke@arcor.de> wrote:
we use "vercmp" to create our diffscript http://archlinux.org/~andyrtr/pkg_diff.html
vercmp still reports 0.8.10a < 0.8.10
that's why we have to use force='y' in our PKGBUILDS that also appears in pkgdesc
shouldn't we fix this before the release?
Not going to happen, bugfix only period has started, and Aaron and I would consider this feature addition.
If this was an easy fix it would have been fixed in pacman long ago. This is *why* force=y exists. There is absolutely no definitive way to determine alphanumeric versioning. Does 1.0a come after 1.0? Or is it 1.0 "alpha"? There's a million questions here. Frankly, I know there is no way to fix this 100% of the time. If you feel it's a fixable problem, I suggest you submit a patch with a solution.
participants (4)
-
Aaron Griffin
-
Andreas Radke
-
Dan McGee
-
Roman Kyrylych