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#13416 - [makepkg] bug in scm packages and pkgrel updating

Attached to Project: Pacman
Opened by Allan McRae (Allan) - Sunday, 22 February 2009, 10:47 GMT
Last edited by Allan McRae (Allan) - Tuesday, 24 February 2009, 08:32 GMT
Task Type Bug Report
Category makepkg
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.1
Due in Version 3.3.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

makepkg always sets the pkgrel to 1 in SCM PKGBUILDs. It should only do this when updating the pkgrel.

e.g. when building notify-sharp-svn 3009-3 I get:
> makepkg
==> Determining latest svn revision...
-> Version found: 3009
==> Making package: notify-sharp-svn 3009-1 i686 (Sat Jan 31 13:20:51 EST 2009)

Probably due to this commit (http://projects.archlinux.org/?p=pacman.git;a=commit;h=1e656c0a) where I fixed this...
This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 24 February 2009, 08:32 GMT
Reason for closing:  Fixed
Additional comments about closing:  Commit a309a016
Comment by Dan McGee (toofishes) - Sunday, 22 February 2009, 16:31 GMT
So only set it to one if we actually change the pkgver? Or what do you propose?
Comment by Xavier (shining) - Sunday, 22 February 2009, 17:16 GMT
Well yes, that would make sense.
What about reverting just the first change from that patch?
+ pkgrel=1
Comment by Dan McGee (toofishes) - Sunday, 22 February 2009, 17:32 GMT
I think the intent was to keep the pkgrel from staying high when upping the pkgver- however, this can't be done if the pkgver doesn't actually change.
Comment by Xavier (shining) - Sunday, 22 February 2009, 18:09 GMT
Allan's patch had two parts, I was just wondering what the first part was for. What happens if we revert the first but keep the second part?
Comment by Allan McRae (Allan) - Sunday, 22 February 2009, 20:27 GMT
Actually having a look at the patch, I have no idea why the pkgrel=1 is there and I would say that is the cause of the bug. As Xavier said, this should go.

Loading...