Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#14887 - Using timestamps to help pacman offer a solution to packages that have weird upstream versioning
Attached to Project:
Pacman
Opened by jasin (rooloo) - Saturday, 30 May 2009, 23:06 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 12 January 2011, 06:24 GMT
Opened by jasin (rooloo) - Saturday, 30 May 2009, 23:06 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 12 January 2011, 06:24 GMT
|
DetailsDescription: Feature request for pacman.
warning: oss: local (4.1_1052-1) is newer than community (4.1_1052b-1) After some discussion on irc it sort of hit me that maybe these sort of warnings can be squished/eliminated or at the very least have pacman offer a solution as to which is the newer package by using timestamps on when packages where built. I don't really see an issue with this unless the packagers system clock is off. But even this can be screened for, one could check not so much the time but maybe just the date of packages being uploaded to the official repositories. Just a thought Additional info: Latest pacman package. |
This task depends upon
Closed by Dan McGee (toofishes)
Wednesday, 12 January 2011, 06:24 GMT
Reason for closing: Won't implement
Additional comments about closing: Will be fixed by epoch in 3.5.0
Wednesday, 12 January 2011, 06:24 GMT
Reason for closing: Won't implement
Additional comments about closing: Will be fixed by epoch in 3.5.0
options=('force')
from man:PKGBUILD
options (array)
<snip>
force
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). See linkman:pacman[8] for more
infomation on version comparisons.
In any reguard, this presents now as a bug report for the above aformentioned reason.
RPM uses EPOCH to workaround this problem: http://sial.org/howto/rpm/epoch/
I don't like the frequent use of force, since the dependency check ignores force field. And two foo packages with force cannot be compared.
Well I didn't think anyone would actually upload a old package to the server.
I still think this needs more thought on what can be done. The end user really shouldn't have to worry about running pacman -S oss after running -Syu when oss is installed. Whether the fix be on the packagers side or the pacman side. Arch is supposed to adhere to the KISS method. There is nothing intuitive or simple about installing something that is already installed just to see it being updated.
I guess the complexity of fixing the issue is greater then the effect to the end user, thus it should remain as is?