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#35426 - [pacman] makepkg --holdver doesn't hold version while building a package

Attached to Project: Pacman
Opened by Alain Kalker (ackalker) - Wednesday, 22 May 2013, 17:53 GMT
Last edited by Allan McRae (Allan) - Thursday, 23 May 2013, 00:19 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Using two consecutive runs of:
$ makepkg -Lsf --holdver
on a modified PKGBUILD for sdrsharp-svn (see attached taurball), the following two (related?) things go wrong:

- On the first run, the correct SVN revision is fetched and a package is built, but the package's version is the latest revision, not the specified (supposed to be held) one.
- On the second run, the build fails due to a change introduced in a later revision (which was the reason to use --holdver in the first place).

Looking at the PKGBUILD shows that the version number was updated despite the --holdver option.

Additional info:
* package version(s)
- pacman 4.1.1-1
* config and/or log files etc.
- taurball (see attachment)
- build logs (see attachment)
Steps to reproduce:
- Extract the taurball
$ makepkg -Lsf --holdver
(move log files out of the way)
$ makepkg -Lsf --holdver
(application/x-gzip)    sdrsharp-svn-1134-1.src.tar.gz (1.5 KiB)
   buildlogs.tar.xz (4.5 KiB)
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 23 May 2013, 00:19 GMT
Reason for closing:  Fixed
Additional comments about closing:  Works in pacman 4.1.1
Comment by Alain Kalker (ackalker) - Wednesday, 22 May 2013, 18:03 GMT
Snippet from terminal output for first build (missing from log :-( , ):
[...]
Checked out revision 1135.
-> Found sdrsharp.desktop
==> Validating source files with md5sums...
sdrsharp ... Skipped
sdrsharp.desktop ... Passed
==> Extracting sources...
-> Creating working copy of trunk svn repo...
Updating '.':
D DNR
U SDRSharp.sln
U SDRSharp/App.config
Updated to revision 1134.
==> Starting pkgver()...
==> Updated version: sdrsharp-svn 1135-1
==> Starting build()...
[...]

Snippet from terminal output for second build:
[...]
==> Extracting sources...
-> Creating working copy of trunk svn repo...
Updating '.':
At revision 1135.
==> Starting pkgver()...
==> Removing existing pkg/ directory...
==> Starting build()...
[...]

Clearly the "Updated version: sdrsharp-svn 1135-1" shouldn't have happened when using --holdver.
Comment by Dave Reisner (falconindy) - Wednesday, 22 May 2013, 18:07 GMT
Appears to be specific to SVN -- git works just fine here.
Comment by Alain Kalker (ackalker) - Wednesday, 22 May 2013, 18:40 GMT
This seems to be related to the fact there is no SVN metadata in $srcdir/<pkgname>, so we have to use $SRCDEST/<pkgname> dir inside pkgver() function.
It appears that for SVN, the pristine 'mirror' repo is always kept at the latest revision, while the working tree is at the PKGBUILD-specified revision.

I'm wondering: wouldn't a simple fix be to just skip the call to pkgver() and the PKGBUILD version update altogether?
Comment by Alain Kalker (ackalker) - Wednesday, 22 May 2013, 18:58 GMT
Ah! It appears that the $SRCDEST/<pkgname> in pkgver() is an old workaround for the metadata problem that is no longer relevant. The metadata is now in the working tree, and svnversion works as expected.
(There are a boatload of PKGBUILDs in the AUR that need fixing ;-) )

Please close this bug if you want, thanks for looking into this.

Loading...