[aur-general] TU Application: Baptiste Jonglez

[Eli Schwartz]

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