Here's how I was told the correct way to handle it was: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mono-git#n57 I've got a few more that use git submodules as well: ags-git and rofi-git are ones I know offhand.
Implement noextract=() for source/git.sh to avoid having two checkouts with that ugly layer of indirection.
+1 On Mon, Jul 31, 2017 at 2:52 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 07/31/2017 03:35 PM, Doug Newgard wrote:
On Mon, 31 Jul 2017 14:16:33 -0400 Eli Schwartz <eschwartz@archlinux.org> wrote:
You're both right and wrong. "$srcdir/$submodulename" will be at origin/master, but `git submodule update` in the primary repo will completely ignore that clone altogether and just cares about the git objects which it uses in yet another clone.
This is a bit confusing. You set the URL of the submodule to the location of the local clone, so it doesn't ignore it, it just clones from the local clone. And yes, it does use the specific commit specified in the main repo, so setting #commit= for the submodule is useless.
Yeah, that. Although now I am starting to think...
I don't have any PKGBUILDs that do this myself. So it's never really been on my radar. However, I am wondering if it would make more sense to allow/use: - $SRCDEST/$repo for the submodule url. The variable should be accessible, we just don't document its availability for use in a PKGBUILD. - Implement noextract=() for source/git.sh to avoid having two checkouts with that ugly layer of indirection. - Update the "VCS package guidelines" wiki page
-- Eli Schwartz