[pacman-dev] [PATCH] Add information on version comparison to manpages

newer
[pacman-dev] [PATCH] Additional...

older
[pacman-dev] [GIT] The official...

Dan McGee

20 Jun 2008 20 Jun '08

12:29 a.m.

Signed-off-by: Dan McGee --- 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 -<> below. +<> 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

Show replies by date

Nagy Gabor

20 Jun 20 Jun

8:46 a.m.

New subject: [pacman-dev] [PATCH] Add information on version comparison to manpages

...

Signed-off-by: Dan McGee --- 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 -<> below. +<> 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

Dan McGee

11:09 a.m.

On Fri, Jun 20, 2008 at 3:46 AM, Nagy Gabor wrote:

...

...
Signed-off-by: Dan McGee --- 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 -<> below. +<> 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

Xavier

12:19 p.m.

On Fri, Jun 20, 2008 at 1:09 PM, Dan McGee 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.

Nagy Gabor

12:21 p.m.

New subject: [pacman-dev] [PATCH] Add information on version comparison to manpages

Fri, 20 Jun 2008 06:09:37 -0500 -n "Dan McGee" írta:

...

On Fri, Jun 20, 2008 at 3:46 AM, Nagy Gabor wrote:

...
...
Signed-off-by: Dan McGee --- 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 -<> below. +<> 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

Xavier

12:28 p.m.

2008/6/20 Nagy Gabor :

...

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.

Roman Kyrylych

12:42 p.m.

2008/6/20 Xavier :

...

2008/6/20 Nagy Gabor :

...
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 :

...

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 (Роман Кирилич)

Nagy Gabor

12:48 p.m.

New subject: [pacman-dev] [PATCH] Add information on version comparison to manpages

...

2008/6/20 Xavier :

...
2008/6/20 Nagy Gabor :

...
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 :

...
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

Nagy Gabor

1:03 p.m.

New subject: [pacman-dev] [PATCH] Add information on version comparison to manpages

...

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

Xavier

1:47 p.m.

On Fri, Jun 20, 2008 at 3:03 PM, Nagy Gabor 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.

Xavier

2:01 p.m.

On Fri, Jun 20, 2008 at 2:42 PM, Roman Kyrylych 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.

5798

Age (days ago)

5798

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Dan McGee
Dan McGee
Nagy Gabor
Roman Kyrylych
Xavier