Pacman

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.
Tasklist

FS#17530 - makepkg reset pkgrel for svn/git/cvs/... package when updating pkgver

Attached to Project: Pacman
Opened by solsTiCe (zebul666) - Wednesday, 16 December 2009, 18:47 GMT
Last edited by Allan McRae (Allan) - Wednesday, 23 December 2009, 23:29 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Xavier (shining)
Architecture All
Severity Very Low
Priority Normal
Reported Version 3.3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:
i was following chromium-browser-bin on AUR. and noticed the PKGBUILD was updated quite often. it is now at pkgrel=9. and found that the package i have got still have -1 pkgrel attached to their name.

i found out it was makepkg that reset pkgrel to 1 when it updates pkgver. and i found this odd. because i was excepting the pkgrel to reflect the one used in the PKGBUILD.
in this case pkgrel is used more like PKGBUILD revision or release than a package release

wouldn't it make more sense to not reset to 1 pkgrel for svn/git/cvs/hg/... and let it what it is in the PKGBUILD when updating pkgver ?

resetting pkgrel to 1 was done by commit 1e656c0a6a7f2dcf5d
This task depends upon

Closed by  Allan McRae (Allan)
Wednesday, 23 December 2009, 23:29 GMT
Reason for closing:  Won't implement
Comment by Xavier (shining) - Wednesday, 16 December 2009, 19:01 GMT
I agree that it is debatable. I am fine either way. Allan, Dan ?
Comment by Allan McRae (Allan) - Wednesday, 16 December 2009, 19:01 GMT
The pkgrel reflects the build number for the pkgver. If the pkgver gets updated to the latest, then the pkgrel should go to 1.
Comment by Dan McGee (toofishes) - Wednesday, 16 December 2009, 21:44 GMT
I tend to think the way Allan does as well. If you are not sure what PKGBUILD your local one resembles, the maintainer of the original should probably put some sort of date or something indicating the last revision inside the file instead of depending on the pkgrel.

Loading...