Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#34586 - [pacman] The flaw in work with VCS (git)?

Attached to Project: Arch Linux
Opened by Vladimir (_v_l) - Wednesday, 03 April 2013, 14:19 GMT
Last edited by Allan McRae (Allan) - Thursday, 04 April 2013, 06:01 GMT
Task Type Support Request
Category Packages: Testing
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Let's imagine that I have following directory structure
~/buildpkg/mupdf/
mupdf/
PKGBUILD
for package 'mupdf-git', here 'mupdf/' is local clone of remote git repository. I use 'makepkg' in that directory to build 'mupdf-git' from fresh git 'HEAD'.

In previous version of pacman (actually 'makepkg') I used to manually update local git repository to fresh 'HEAD' in 'PKGBUILD' (as it is recommended in PKGBUILD-git.proto).

New pacman version, 4.1, deprecates the use of '_gitname' and '_gitroot' (they aren't mentioned in manual) and besides that it don't update 'pkgver' as version 4.0.3 did.

I followed guide 'https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines' ("... example of a Git PKGBUILD in pacman 4.1") and get rid of both variables, changed 'sources' and added 'pkgver' function.

I expected that when I run 'makepkg' it would fetch changes from upstream (origin) and update repository. But I was wrong, according to 'makepkg' source (/usr/bin/makepkg), it did fetch changes but not update local repository, so following 'git clone' clones old data. As I understand the code this is intended but strange. Is that expected way to work? In contrast, bzr, svn both update they local repositories, while hg uses the same strategy as git.

If I not fully wrong with my understanding of '-git' ('-bzr', '-svn', '-hg') packages idea, all local repositories (now this only concerns git and hg) have to be updated before any 'clone' operation.
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 04 April 2013, 06:01 GMT
Reason for closing:  Not a bug
Comment by Jelle van der Waa (jelly) - Wednesday, 03 April 2013, 14:35 GMT
Try to mv your current git repo and build it again.
Btw I just cloned expac to $srcdir/expac and building works fine.
Comment by Daniel Wallace (gtmanfred) - Wednesday, 03 April 2013, 14:59 GMT
it updates your local bare repo which is cloned into $SRCDEST , and then re clones that into the $srcdir with a makepkg branch for you to build in
Comment by Dave Reisner (falconindy) - Wednesday, 03 April 2013, 15:18 GMT
Assuming that you even have a bare repo... I think you need to reset your expectations by starting with a clean build environment.
Comment by KaiSforza (KaiSforza) - Wednesday, 03 April 2013, 18:14 GMT
If you are cloning manually in the pkgbuild, then you are doing it wrong. makepkg will clone the repo for you. Notice in the example it just cd's and makes. No user written function in the pkgbuild should be running `git clone` or manipulating the $SRCDEST git repository. Let's say that you set SRCDEST to ~/.makepkg/src, and your builddir is ~/.makepkg/build.

~/.makepkg/src/$pkgname <-- bare git repo pulled in by makepkg (assuming the git repo is the same name as the package)
~/.makepkg/build/$pkgname/src/$pkgname <-- non-bare git repo cloned by makepkg for building purposes, also known as "$srcdir/$pkgname"

All of the building happens in ~/.makepkg/build, and the non-bare repo is automagically generated. This could have been made by a PKGBUILD with just a package function that goes

package () { cd "$srcdir/$pkgname" ; make install }

No build function, no cloning in the PKGBUILD, nothing special for git. It's extracted in exactly the same way (at least to your packages) as any normal source is.

Loading...