[pacman-dev] [PATCH] Add information on version comparison to manpages
Signed-off-by: Dan McGee <dan@archlinux.org> --- doc/PKGBUILD.5.txt | 3 ++- doc/pacman.8.txt | 8 +++++++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/doc/PKGBUILD.5.txt b/doc/PKGBUILD.5.txt index b90d67a..0b1ce64 100644 --- a/doc/PKGBUILD.5.txt +++ b/doc/PKGBUILD.5.txt @@ -214,7 +214,8 @@ similar to `$_basekernver`. Force the package to be upgraded by a pacman system upgrade operation, even if the version number would normally not trigger such an upgrade. This is useful when the version numbering scheme - of a package changes (or is alphanumeric). + of a package changes (or is alphanumeric). See linkman:pacman[8] for + more infomation on version comparisons. build() Function diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 5594ac6..08764de 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -61,7 +61,13 @@ provide the same functionality as foo will be searched for. If any package is found, it will be installed. + You can also use `pacman -Su` to upgrade all packages that are out of date. See -<<SO,Sync Options>> below. +<<SO,Sync Options>> below. When upgrading, pacman performs version comparison +to determine which packages need upgrading. This behavior operates as follows: + + Alphanumeric: + 1.0 < 1.0a < 1.0alpha < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc + Numeric: + 1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0 *-U, \--upgrade*:: Upgrade or add a package to the system. Either a URL or file path can be -- 1.5.6
Signed-off-by: Dan McGee <dan@archlinux.org> --- doc/PKGBUILD.5.txt | 3 ++- doc/pacman.8.txt | 8 +++++++- 2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/doc/PKGBUILD.5.txt b/doc/PKGBUILD.5.txt index b90d67a..0b1ce64 100644 --- a/doc/PKGBUILD.5.txt +++ b/doc/PKGBUILD.5.txt @@ -214,7 +214,8 @@ similar to `$_basekernver`. Force the package to be upgraded by a pacman system upgrade operation, even if the version number would normally not trigger such an upgrade. This is useful when the version numbering scheme - of a package changes (or is alphanumeric). + of a package changes (or is alphanumeric). See linkman:pacman[8] for + more infomation on version comparisons.
build() Function diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 5594ac6..08764de 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -61,7 +61,13 @@ provide the same functionality as foo will be searched for. If any package is found, it will be installed. + You can also use `pacman -Su` to upgrade all packages that are out of date. See -<<SO,Sync Options>> below. +<<SO,Sync Options>> below. When upgrading, pacman performs version comparison +to determine which packages need upgrading. This behavior operates as follows: + + Alphanumeric: + 1.0 < 1.0a < 1.0alpha < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc
Sorry guys, I don't like this at all. I think the old behavior was better. And I don't see the reason of this change. We have many packages with alphanumeric version atm: a2ps-4.13c-1, aalib-1.4rc5-1, ... and I'm pretty sure that the expected behavior is that aalib-1.4 should upgrade aalib-1.4rc5-1, like earlier. Bye
On Fri, Jun 20, 2008 at 3:46 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Signed-off-by: Dan McGee <dan@archlinux.org> --- doc/PKGBUILD.5.txt | 3 ++- doc/pacman.8.txt | 8 +++++++- 2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/doc/PKGBUILD.5.txt b/doc/PKGBUILD.5.txt index b90d67a..0b1ce64 100644 --- a/doc/PKGBUILD.5.txt +++ b/doc/PKGBUILD.5.txt @@ -214,7 +214,8 @@ similar to `$_basekernver`. Force the package to be upgraded by a pacman system upgrade operation, even if the version number would normally not trigger such an upgrade. This is useful when the version numbering scheme - of a package changes (or is alphanumeric). + of a package changes (or is alphanumeric). See linkman:pacman[8] for + more infomation on version comparisons.
build() Function diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 5594ac6..08764de 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -61,7 +61,13 @@ provide the same functionality as foo will be searched for. If any package is found, it will be installed. + You can also use `pacman -Su` to upgrade all packages that are out of date. See -<<SO,Sync Options>> below. +<<SO,Sync Options>> below. When upgrading, pacman performs version comparison +to determine which packages need upgrading. This behavior operates as follows: + + Alphanumeric: + 1.0 < 1.0a < 1.0alpha < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc
Sorry guys, I don't like this at all. I think the old behavior was better. And I don't see the reason of this change. We have many packages with alphanumeric version atm: a2ps-4.13c-1, aalib-1.4rc5-1, ... and I'm pretty sure that the expected behavior is that aalib-1.4 should upgrade aalib-1.4rc5-1, like earlier.
But what is the expected behavior for a2ps with the 'c' in there? Does 4.13 come before 4.13b? You are saying "I don't like this" without a whole lot of justification and you even gave me a converse example as far as I can tell. And I would tend to trust the upstream RPM guys quite a bit when it comes to version number ordering, as they deal with this a lot. https://bugzilla.redhat.com/show_bug.cgi?id=50977 https://bugzilla.redhat.com/show_bug.cgi?id=178798 -Dan
On Fri, Jun 20, 2008 at 1:09 PM, Dan McGee <dpmcgee@gmail.com> wrote:
But what is the expected behavior for a2ps with the 'c' in there? Does 4.13 come before 4.13b? You are saying "I don't like this" without a whole lot of justification and you even gave me a converse example as far as I can tell. And I would tend to trust the upstream RPM guys quite a bit when it comes to version number ordering, as they deal with this a lot.
https://bugzilla.redhat.com/show_bug.cgi?id=50977 https://bugzilla.redhat.com/show_bug.cgi?id=178798
I was just discussing this problem with Dan and how rpm deals with it, then he mentioned to me the Epoch term. I found a description here : http://sial.org/howto/rpm/epoch/ Come to think about it, this seems much much smarter and better than the FORCE flag, while staying simple enough. This would obsolete this annoying question which had no clear answer : when can we remove the force flag. And it would provide a better workaround for these version problems.
Fri, 20 Jun 2008 06:09:37 -0500 -n "Dan McGee" <dpmcgee@gmail.com> írta:
On Fri, Jun 20, 2008 at 3:46 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Signed-off-by: Dan McGee <dan@archlinux.org> --- doc/PKGBUILD.5.txt | 3 ++- doc/pacman.8.txt | 8 +++++++- 2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/doc/PKGBUILD.5.txt b/doc/PKGBUILD.5.txt index b90d67a..0b1ce64 100644 --- a/doc/PKGBUILD.5.txt +++ b/doc/PKGBUILD.5.txt @@ -214,7 +214,8 @@ similar to `$_basekernver`. Force the package to be upgraded by a pacman system upgrade operation, even if the version number would normally not trigger such an upgrade. This is useful when the version numbering scheme - of a package changes (or is alphanumeric). + of a package changes (or is alphanumeric). See linkman:pacman[8] for + more infomation on version comparisons.
build() Function diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 5594ac6..08764de 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -61,7 +61,13 @@ provide the same functionality as foo will be searched for. If any package is found, it will be installed. + You can also use `pacman -Su` to upgrade all packages that are out of date. See -<<SO,Sync Options>> below. +<<SO,Sync Options>> below. When upgrading, pacman performs version comparison +to determine which packages need upgrading. This behavior operates as follows: + + Alphanumeric: + 1.0 < 1.0a < 1.0alpha < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc
Sorry guys, I don't like this at all. I think the old behavior was better. And I don't see the reason of this change. We have many packages with alphanumeric version atm: a2ps-4.13c-1, aalib-1.4rc5-1, ... and I'm pretty sure that the expected behavior is that aalib-1.4 should upgrade aalib-1.4rc5-1, like earlier.
But what is the expected behavior for a2ps with the 'c' in there? Does 4.13 come before 4.13b? You are saying "I don't like this" without a whole lot of justification and you even gave me a converse example as far as I can tell. And I would tend to trust the upstream RPM guys quite a bit when it comes to version number ordering, as they deal with this a lot.
4.13a < 4.13b < 4.13c < 4.13 (old behavior, my interpretation: alpha, beta, gamma) You may trust rpm guys, but don't forget that rpm based distros usually use different versioning scheme, so '1.0b versus 1.0' is not a real life example there: alsa-lib-1.0.14-0.4.rc3.fc7.i386.rpm (Fedora) mplayer-1.0-0.20.pre7.0.rh9.rf.i386.rpm (Fedora)
https://bugzilla.redhat.com/show_bug.cgi?id=50977 https://bugzilla.redhat.com/show_bug.cgi?id=178798
Could you show me a vercmptest entry? Bye
2008/6/20 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
You may trust rpm guys, but don't forget that rpm based distros usually use different versioning scheme, so '1.0b versus 1.0' is not a real life example there: alsa-lib-1.0.14-0.4.rc3.fc7.i386.rpm (Fedora) mplayer-1.0-0.20.pre7.0.rh9.rf.i386.rpm (Fedora)
Yeah, I was also thinking about that. But what is strange is that in the rpm epoch link I just gave, they give an example that matches our situation.
2008/6/20 Xavier <shiningxc@gmail.com>:
2008/6/20 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
You may trust rpm guys, but don't forget that rpm based distros usually use different versioning scheme, so '1.0b versus 1.0' is not a real life example there: alsa-lib-1.0.14-0.4.rc3.fc7.i386.rpm (Fedora) mplayer-1.0-0.20.pre7.0.rh9.rf.i386.rpm (Fedora)
Yeah, I was also thinking about that. But what is strange is that in the rpm epoch link I just gave, they give an example that matches our situation.
Not to say that I think the new vercmp is "wrong" and the old one is "correct", but 2008/6/15 Miklos Vajna <vmiklos@frugalware.org>:
1.0rc < 1.0 -> good 1.0pre < 1.0 -> good 1.0alpha < 1.0 -> good 1.0beta < 1.0 -> good 1.0a < 1.0 -> bad 1.0b < 1.0 -> bad 1.0b (if 'a' stands for alpha) < 1.0 -> good 1.0b (if 'b' stands for beta) < 1.0 -> good
so it was 6 good vs 2 bad while now it's 6 bad vs 2 good, if i haven't miscounted something.
the old vercmp also maintains backwards compatibility, i.e. packages that used to have options=('force') (e.g. samba) will still have it, and packages that used to not have options=('force') when using *{rc,beta,pre} won't need it. (I didn't counted anything though :-P). I mostly dislike the change just because it will require removing/adding options=('force') to packages without a real need (IMO). /me shrugs -- Roman Kyrylych (Роман Кирилич)
2008/6/20 Xavier <shiningxc@gmail.com>:
2008/6/20 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
You may trust rpm guys, but don't forget that rpm based distros usually use different versioning scheme, so '1.0b versus 1.0' is not a real life example there: alsa-lib-1.0.14-0.4.rc3.fc7.i386.rpm (Fedora) mplayer-1.0-0.20.pre7.0.rh9.rf.i386.rpm (Fedora)
Yeah, I was also thinking about that. But what is strange is that in the rpm epoch link I just gave, they give an example that matches our situation.
Not to say that I think the new vercmp is "wrong" and the old one is "correct", but
2008/6/15 Miklos Vajna <vmiklos@frugalware.org>:
1.0rc < 1.0 -> good 1.0pre < 1.0 -> good 1.0alpha < 1.0 -> good 1.0beta < 1.0 -> good 1.0a < 1.0 -> bad 1.0b < 1.0 -> bad 1.0b (if 'a' stands for alpha) < 1.0 -> good 1.0b (if 'b' stands for beta) < 1.0 -> good
so it was 6 good vs 2 bad while now it's 6 bad vs 2 good, if i haven't miscounted something.
the old vercmp also maintains backwards compatibility, i.e. packages that used to have options=('force') (e.g. samba) will still have it, and packages that used to not have options=('force') when using *{rc,beta,pre} won't need it. (I didn't counted anything though :-P).
I mostly dislike the change just because it will require removing/adding options=('force') to packages without a real need (IMO). /me shrugs
Yes. And in Xavier's link there is a "Problems with Dependencies" paragraph. So it is required to minimize force/epoch in order to calculate 'foo>=1.3-1' dependencies correctly. Question: any foo package with force will satisfy this. Right? Bye
Yes. And in Xavier's link there is a "Problems with Dependencies" paragraph. So it is required to minimize force/epoch in order to calculate 'foo>=1.3-1' dependencies correctly. Question: any foo package with force will satisfy this. Right?
Wrong. alpm_depcmp uses versioncmp instead of compate_version, so doesn't deal with force. Bye
On Fri, Jun 20, 2008 at 3:03 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Yes. And in Xavier's link there is a "Problems with Dependencies" paragraph. So it is required to minimize force/epoch in order to calculate 'foo>=1.3-1' dependencies correctly. Question: any foo package with force will satisfy this. Right?
Wrong. alpm_depcmp uses versioncmp instead of compate_version, so doesn't deal with force.
That's correct. But if we want to deal with force/epoch in depcmp, epoch also seems better here, since it is more precise than force.
On Fri, Jun 20, 2008 at 2:42 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
the old vercmp also maintains backwards compatibility, i.e. packages that used to have options=('force') (e.g. samba) will still have it, and packages that used to not have options=('force') when using *{rc,beta,pre} won't need it. (I didn't counted anything though :-P).
I mostly dislike the change just because it will require removing/adding options=('force') to packages without a real need (IMO). /me shrugs
Well I am not sure that is relevant, given the current status of this force flag. Half of the packages that used force use the old force=y option which is no longer supported. And the big majority of the packagers using options=(force) haven't been rebuilt and re-added to the database with the new repo-add so their force flag is currently not in effect. We have something like 65 official PKGBUILDs with the force options, and there are less than 10 which actually appear in the databases. http://www.archlinux.org/pipermail/arch-dev-public/2008-May/006243.html So my proposal would be to remove force flag from all these pkgbuilds, and re-add them when they are needed. If this new behavior of vercmp is kept, this change should probably be made after 3.2 is released.
participants (5)
-
Dan McGee
-
Dan McGee
-
Nagy Gabor
-
Roman Kyrylych
-
Xavier