[aur-general] TU Application: Baptiste Jonglez

Levente Polyak anthraxx at archlinux.org
Mon Nov 28 16:26:25 UTC 2016


On 11/28/2016 05:05 PM, Eli Schwartz via aur-general wrote:
> On 11/28/2016 06:20 AM, Levente Polyak wrote:
>> - #tag= should never be used for git packages, instead store the commit
>>   hash for the tag and always use the #tag= prefix.
> 
> Typo?
> 

uuups, you caught me :P My bad! Of cause this should be #commit=
Thanks Eli!

>>   A named tag does not mean much and you won't even notice when upstream
>>   changes such. This is especially bad when using plain git:// :-)
> 
> Well, I should hope upstream doesn't re-release their tags... if so, you
> might have other problems.

Well I already encountered a re-release at least twice, shame on them!
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)

> But from the repo PKGBUILDs I have seen, it seems to me as though there
> is no policy whatsoever... some devs do like you suggest, other devs are
> more than happy to use "#tag=$pkgver".

Well i assume "more happy" just means "able to be more lazy" (without
any offense to anyone!) :P

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 :)

> 
>> udrawgraph
>> - just a bit of style, but we have arch specific depends like
>>   depends_x86_64 which looks better :P
> 
> That isn't "style", that is something that *must* be done, for practical
> purposes. makepkg --printsrcinfo relies on arch-dependent variables that
> are *always* there, in order to actually print truthful values. Also,
> arch-dependent sources done properly will allow updpkgsums to properly
> update, rather than merging the local *sums_$CARCH into the main
> checksums array.
> 
> All that matters a lot in the AUR, which depends on .SRCINFO, even if it
> doesn't matter so much in the repos which depend on the metadata in a
> built package.
> 

Fair enough... that's a pretty good point why it should be mandatory.
Did not really take the .SRCINFO into account for this particular case.

>> 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.

cheers,
Levente

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161128/0b4c1a9c/attachment.asc>


More information about the aur-general mailing list