Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Pacman Development (http://www.linux-archive.org/archlinux-pacman-development/)
-   -   Add information on version comparison to manpages (http://www.linux-archive.org/archlinux-pacman-development/110050-add-information-version-comparison-manpages.html)

Dan McGee 06-20-2008 12:29 AM

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


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

"Dan McGee" 06-20-2008 11:09 AM

Add information on version comparison to manpages
 
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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Xavier 06-20-2008 12:19 PM

Add information on version comparison to manpages
 
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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Xavier 06-20-2008 12:28 PM

Add information on version comparison to manpages
 
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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

"Roman Kyrylych" 06-20-2008 12:42 PM

Add information on version comparison to manpages
 
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 (*оман Кирилич)
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Xavier 06-20-2008 01:47 PM

Add information on version comparison to manpages
 
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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Xavier 06-20-2008 02:01 PM

Add information on version comparison to manpages
 
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.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev


All times are GMT. The time now is 03:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.