On 11/28/2016 11:26 AM, Levente Polyak wrote:
When using a commit hash you gain basically two things out of the box: - get aware if wonky upstream changes something - get an integrity value that a potential attacker must defeat, which not be the easiest task for a full commit hash (for a short partial hash there are of cause some PoC's/tools available)
Hmm, that is true. git has builtin integrity checks but also ends up almost completely lacking in any capacity for authentication. At least as far as makepkg is concerned. As a user, I think I would still prefer tarballs rather than unnecessary git history... but if you must use git for non-VCS packages then commit hashes are useful.
In fact we already had several discussions in the IRC about this topic and what I mentioned above was always sufficient to justify getting rid of it. The only reason we don't yet have a TODO list to switch away from #tag= is simply lack of time (but its still on my todo list besides getting a TODO list for git:// sources).
If a remember correctly either heftig or JGC has created a convenience script to update a PKGBUILDs values, maybe they share it with us :)
That is very interesting information, thanks for mentioning it. My curiosity is now sated. :)
net-tools-mptcp - #branch= should never be used for non VCS git packages, instead store the commit hash for the tag and always use the #tag= prefix. A named branch does not mean much and you won't even notice when upstream changes or adds commits to such.
It has a pkgver() function which generates a VCS-style pkgver, and draws from a #branch= so actually it is a VCS git package. The problem is that it doesn't say so in the pkgname. :p
Well yes... and no... though the same while looking at it but at the end I'm not quite sure what the intention of Baptiste is. As the branch used is a simple version identifier, I assumed he pretty much wanted to have a static versioned package. pkgver() itself does not tell us which one it should be, if you have a static version package that pulls from a git commit hash you can have a pkgver() function for convenience.
I have noticed that trick in repo packages, yeah. But this is pulling from a branch... anything that has changing sources would be VCS, except that without both #branch= and a pkgver() it is merely broken beyond repair. Now, while some projects do use versioned branches to separate development on apparently incompatible release branches, it could be that this upstream only commits to that branch when releasing, and otherwise it will never get new commits (so it is a static versioning branch, and the tag itself wasn't used for inexplicable reasons which justify themselves because "because"). I couldn't be bothered to read the PKGBUILD *and* check the upstream sources, just to make random comments about style. :p (If so, why does the pkgver function specifically use `git describe --long` when `git describe` would by default exclude "r0.guselesshashpointingtoatag"` ???) But either way, you said "you won't even notice when upstream changes or adds commits to such" and the *current* pkgver function guarantees he *will* notice. -- Eli Schwartz