[arch-general] perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1) I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but.. The question is, should pacman think that 2.1401 is newer than 2.15 ? -- damjan
On 07/20/2010 06:14 PM, Damjan Georgievski wrote:
This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but..
The question is, should pacman think that 2.1401 is newer than 2.15 ?
note. this is a bug. http://repos.archlinux.org/wsvn/community/perl-authen-sasl/trunk/PKGBUILD?op... the maintainer should have added a force option -- Ionuț
On 20/07/10 18:14, Damjan Georgievski wrote:
This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but..
The question is, should pacman think that 2.1401 is newer than 2.15 ?
Looks like perl-authen-sasl 2.15 should have the 'force' option set. The minor version number is going from 1401 to 15, and that causes pacman to assume it's an older release. I posted a bug report: http://bugs.archlinux.org/task/20238.
On Tue 20 Jul 2010 17:14 +0200, Damjan Georgievski wrote:
This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but..
The question is, should pacman think that 2.1401 is newer than 2.15 ?
I would hope so. 1401 > 15
On Tue, Jul 20, 2010 at 5:55 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Tue 20 Jul 2010 17:14 +0200, Damjan Georgievski wrote:
This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but..
The question is, should pacman think that 2.1401 is newer than 2.15 ?
I would hope so. 1401 > 15
at the same time.... ----------------------------------------- # ls -1 num/ 1 10 11 12 13 14 15 16 17 18 19 2 20 3 4 5 6 7 8 9 ----------------------------------------- :-D C Anthony
On Tue, Jul 20, 2010 at 07:34:10PM -0500, C Anthony Risinger wrote:
On Tue, Jul 20, 2010 at 5:55 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Tue 20 Jul 2010 17:14 +0200, Damjan Georgievski wrote:
This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but..
The question is, should pacman think that 2.1401 is newer than 2.15 ?
I would hope so. 1401 > 15
at the same time....
[snipped ls output]
:-D
C Anthony
Sure, because ls is ignorant of the fact that its sorting numbers versus letters. From a lexicographical perspective, what ls is doing above is correct. If you pass the data along to something that actually takes into account that its sorting numbers... $ ls -1 | sort -n 1 2 3 4 5 6 7 8 9 10 11 12 13 ... you get the point Pacman follows its own rules, as described in the man page. 1401 should be newer than 15, but of course upstream should have, imo, versioned it as 2.14.01 to avoid this kind of nonsense. dave
On Wed, Jul 21, 2010 at 12:35 AM, Dave Reisner <d@falconindy.com> wrote:
, but of course upstream should have, imo, versioned it as 2.14.01 to avoid this kind of nonsense.
to upstream that translates to 2.014001 which is less than 2.15 honestly what upstream should have done is made 2.1401 2.15 and now 2.15 would be 2.16 -- Caleb Cushing http://xenoterracide.blogspot.com
On Wed, Jul 21, 2010 at 12:45 AM, Caleb Cushing <xenoterracide@gmail.com> wrote:
which is less than
2.15
err.. 2.14 -- Caleb Cushing http://xenoterracide.blogspot.com
This is prolly a stupid idea but I'll suggest it anyway. Have anyone thought of simply adding another field in the pkginfo, say altver which if present would override pkgver. I'm pretty sure it would walk right around all this nonsense until(if ever) upstream starts using better version schemes. It would also fix? the issue with version dependencies of -svn(et al.) packages where the actual version is e.g 2.1 but the version in the pkginfo is 2432.
On 21/07/10 15:32, Nathan Wayde wrote:
This is prolly a stupid idea but I'll suggest it anyway. Have anyone thought of simply adding another field in the pkginfo, say altver which if present would override pkgver. I'm pretty sure it would walk right around all this nonsense until(if ever) upstream starts using better version schemes. It would also fix? the issue with version dependencies of -svn(et al.) packages where the actual version is e.g 2.1 but the version in the pkginfo is 2432.
There has been talk about adding an epoch variable similar to what rpm does. But this has not progressed beyond talk... Allan
On Tue, Jul 20, 2010 at 6:55 PM, Loui Chang <louipc.ist@gmail.com> wrote:
I would hope so. 1401 > 15
I'm trying to get upstream not to do this stuff. I know we've convinced a few unfortunately most of it's reactive not proactive. -- Caleb Cushing http://xenoterracide.blogspot.com
participants (9)
-
Allan McRae
-
C Anthony Risinger
-
Caleb Cushing
-
Damjan Georgievski
-
Dave Reisner
-
Evangelos Foutras
-
Ionuț Bîru
-
Loui Chang
-
Nathan Wayde