Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#6834 - Pacman 3.0.1 pkg version check fail (1.8b < 1.8)

Attached to Project: Pacman
Opened by DarĂ­o A. (darzephyr) - Saturday, 07 April 2007, 18:26 GMT
Last edited by Roman Kyrylych (Romashka) - Thursday, 31 May 2007, 08:44 GMT
Task Type Bug Report
Category
Status Closed
Assigned To Roman Kyrylych (Romashka)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I have pacman 3.0.1 from testing.
When I do pacman -Syu I get:

warning: nas: local (1.8-2) is newer than community (1.8b-1)

But, I think 1.8b > 1.8
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Thursday, 31 May 2007, 08:44 GMT
Reason for closing:  Deferred
Comment by Roman Kyrylych (Romashka) - Saturday, 07 April 2007, 18:42 GMT
hm, but for some packages 1.8b < 1.8 (b means beta for some packages)
this is not a bug, this is just technical limitation, and is already wide-known.
Comment by Roman Kyrylych (Romashka) - Saturday, 07 April 2007, 18:46 GMT
Workaround: force=y in 1.8b PKGBUILD
Solution: use package build date instead of version for making decision which package is newer (already proposed on ML), though this should be thorougly tested.
Comment by Roman Kyrylych (Romashka) - Saturday, 07 April 2007, 18:54 GMT
previous bugs:
http://bugs.archlinux.org/task/2244
http://bugs.archlinux.org/task/5388
and few others which I cannot find now.
Comment by Dan McGee (toofishes) - Saturday, 07 April 2007, 19:18 GMT
Pacman has never handled this. It is not possible to compare non-numeric versions and know what the original author meant. 'b' could be 'beta' or 'version b' of the software, and it is not our job to regulate that.
Comment by Jan de Groot (JGC) - Saturday, 14 April 2007, 00:04 GMT
This is from the times when we used testing and staging packages:

1t1, 1t2, 1s1, 1s2, etc. After the package was tested, it would get rebuilt for the normal repos, meaning the 1t1 would become 1, which is assumed newer. We workaround this feature by using capitals in the pkgver for official packages. An example for this is samba. Another option is the use of the force flag.
Comment by Dan McGee (toofishes) - Thursday, 31 May 2007, 07:10 GMT
Any reason to keep this open?
Comment by Roman Kyrylych (Romashka) - Thursday, 31 May 2007, 08:38 GMT
I think the only way to solve this issue without the need for force=y workaround is to use package timestamps for version comparison, so I suggest to close this bug as Deferred.

EDIT: I kept this open to not forget that I want to do this change.

Loading...