Using new VCS syntax in PKGBUILD?

[aplund]

Can anyone here help me understand the issues I raised in this pull request and why using the new VCS syntax is the wrong thing to do.

https://github.com/archlinuxarm/PKGBUILDs/pull/999

I've had no response from my questions there.

[pepedog]

I prefer the method where just a specific _commit= is defined, you know what your getting, as in
https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-imx6-cubox-dt/PKGBUILD
Plus you didn't bump pkgrel so builder would never pick it up

[WarheadsSE]

Then there is also the fact of a full git tree checkout vs the ability for hosts like github to generate a tarball of a checkout at the given commit hash, reducing load on the automation greatly. (and is cachable)

[aplund]

$this->bbcode_second_pass_quote('WarheadsSE', 'T')hen there is also the fact of a full git tree checkout vs the ability for hosts like github to generate a tarball of a checkout at the given commit hash, reducing load on the automation greatly. (and is cachable)

[WarheadsSE]

When you distribute your builds across multiple hosts for parallel building of multiple different packages, you loose the bonus of this filesystem caching. We have a squid proxy in front of our build hosts (8x XU) that then farm distcc out to x86-64 cross (as per our documentation). Since these host have entirely separate roots, do not share a common nfs, and have their state purged after every package build (makechrootpkg from inside an arch-chroot) we would see no acceleration as there is no state kept ever. If you only ever have a single build host, or share a common layer in a stacked/network filesystem, the VCS methods might help.

TL;DR - our distributed build system can not benefit from these VCS methods in such that they cache a copy of the checkout to the local filesystem.