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 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:45 AM, Caleb Cushing wrote:

which is less than

2.15

err.. 2.14 -- Caleb Cushing http://xenoterracide.blogspot.com

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