Use unified sources for split PKGBUILDs/better slit package support

[ghost]

Hey! Came across an interesting behaviour...

If one downloads a split PKGBUILD tarball (e.g. I maintain https://aur.archlinux.org/pkgbase/nquake/ which builds.. 6? packages, i think) and runs makepkg against the PKGBUILD manually, it uses the same sources for all split packages (as well it should, since that's what split packages are designed for).

However, if one builds with apacman, the sources get re-downloaded with each sub-package. additionally, the sub-packages don't get saved to /var/cache/apacman/pkg/ (though i'm not sure if that's expected behavior or not).

for example:

manually:

[bts@dawid nquake]$ ls
addon-clanarena.zip  addon-textures.zip  gpl.zip    non-gpl.zip                        nquake-base-2.3-4-any.pkg.tar.xz      nquake.install                       nquake-textures-2.3-4-any.pkg.tar.xz  PKGBUILD
addon-fortress.zip   CC0-1.0             linux.zip  nquake-arena-2.3-4-any.pkg.tar.xz  nquake-fortress-2.3-4-any.pkg.tar.xz  nquake-nonfree-2.3-4-any.pkg.tar.xz  pkg                                   src

apacman (in the $TMPDIR/pkgbuild-$UID? dir):

[bts@dawid pkgbuild-0]$ ls */*
nquake-arena/nquake-arena.tar.gz  nquake-fortress/nquake-fortress.tar.gz  nquake-nonfree/nquake-nonfree.tar.gz  nquake-textures/nquake-textures.tar.gz

nquake-arena/nquake-arena:
addon-clanarena.zip  addon-textures.zip  gpl.zip    non-gpl.zip                        nquake-base-2.3-4-any.pkg.tar.xz      nquake.install                       nquake-textures-2.3-4-any.pkg.tar.xz  PKGBUILD
addon-fortress.zip   CC0-1.0             linux.zip  nquake-arena-2.3-4-any.pkg.tar.xz  nquake-fortress-2.3-4-any.pkg.tar.xz  nquake-nonfree-2.3-4-any.pkg.tar.xz  pkg                                   src

nquake-fortress/nquake-fortress:
addon-clanarena.zip  addon-textures.zip  gpl.zip    non-gpl.zip                        nquake-base-2.3-4-any.pkg.tar.xz      nquake.install                       nquake-textures-2.3-4-any.pkg.tar.xz  PKGBUILD
addon-fortress.zip   CC0-1.0             linux.zip  nquake-arena-2.3-4-any.pkg.tar.xz  nquake-fortress-2.3-4-any.pkg.tar.xz  nquake-nonfree-2.3-4-any.pkg.tar.xz  pkg                                   src

nquake-nonfree/nquake-nonfree:
addon-clanarena.zip  addon-textures.zip  gpl.zip    non-gpl.zip                        nquake-base-2.3-4-any.pkg.tar.xz      nquake.install                       nquake-textures-2.3-4-any.pkg.tar.xz  PKGBUILD
addon-fortress.zip   CC0-1.0             linux.zip  nquake-arena-2.3-4-any.pkg.tar.xz  nquake-fortress-2.3-4-any.pkg.tar.xz  nquake-nonfree-2.3-4-any.pkg.tar.xz  pkg                                   src

nquake-textures/nquake-textures:
addon-clanarena.zip  addon-textures.zip  gpl.zip    non-gpl.zip                        nquake-base-2.3-4-any.pkg.tar.xz      nquake.install                       nquake-textures-2.3-4-any.pkg.tar.xz  PKGBUILD
addon-fortress.zip   CC0-1.0             linux.zip  nquake-arena-2.3-4-any.pkg.tar.xz  nquake-fortress-2.3-4-any.pkg.tar.xz  nquake-nonfree-2.3-4-any.pkg.tar.xz  pkg                                   src

maybe either:

• some test logic (if file exists, then symlink into the current sub-packages)
  • pros: saves disk space, minimal modification needed to apacman
  • cons: still a bit messy
• copy in source files if they exist
  • pros: even less work
  • cons: messy AND chews up disk/tmpfs space
• restructure the build method (so that ALL source packages are cached in, say, /var/cache/apacman/sources - this is how gentoo's portage handles source files, by placing them into /usr/portage/distfiles)
  • pros: would support not having to re-download VCS packages easier as well, and might work by just creating a static ~ for aurbuild user, copying in a ~/.makepkg.conf, and editing the SRCDEST
  • cons: if it doesn't "just work" by doing that ^ then it'd require a LOT of modification. plus system makepkg.conf and aurbuild's ~/.makepkg.conf might become easily out of sync if user makes frequent/advanced customizations to /etc/makepkg.conf, causing some potentially confusing behaviour
• add support for installing from/searching by pkgbase. similar to the manual method above- download the src tarball, unpack, cd into it, and then makepkg (or makepkg --pkg.. see below)
  • for non-split packages, https://aur.archlinux.org/pkgbase/<pkgname>/ redirects to https://aur.archlinux.org/packages/<pkgname>/ so you wouldn't need to modify much in terms of method
  • pros: by simply changing the URI scheme for packages, you could support displaying pkgbases in search results as well as sub-packages of split packages. meaning one could install/search for the entire package set or (i believe) just a sub-package (makepkg --pkg <sub-package> supports this)
  • cons: can be tricky to design.. would probably require more work than above

overall, i'd suggest the last option as it offers the greatest flexibility and would add better support for split packages overall, would GREATLY speed up building of split packages (nvidia beta drivers, anyone?), and would be a good mix of effort vs. payoff, i think.

[oshazard]

@bts368 Method 1 has been implemented in apacman v2.0 (aa86d596eaf85fb993f7d7a5e4b6570c5fc2fd0f)

[rmarquis]

@oshazard Imho, you should still consider the last option for a later version. Making the helper behave exactly as the manual process avoids a lot of little bugs and side effects here and there. That's how it is implemented in pacaur.

[oshazard]

Deprecated by makepkg (resolved in #61)