[aur-general] TU Application: Baptiste Jonglez

[Baptiste Jonglez]

Hi,

On Mon, Nov 28, 2016 at 12:20:40PM +0100, Levente Polyak wrote:
> > Don't hesitate if you have any questions, or comments on my AUR packages!
> 
> Sure, I always take a look at all packages of an applicant and suggest
> changes before I decide how to vote... so here we go :P

Yes, I was expecting this :)

> pjproject
> - if you must use -j1 for every make call, you can simply add
>   !makeflags to the options instead.

Good catch, this was actually copied unchanged from the pjproject package
<https://aur.archlinux.org/packages/pjproject>.

I just tested building in parallel on a 16-core machine, and it works
fine, so I removed the -j1.  The original issue must have been fixed
upstream.

> linux-mptcp
> - #tag= should never be used for git packages, instead store the commit
>   hash for the tag and always use the #tag= prefix. 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:// :-)

Interesting, I had never thought about this issue.

I think I will switch to a tarball as suggested by Eli, I didn't know that
github provides tarballs for each commit.  The downside is that $pkgver
will no longer be computed automatically, I will have to update it
manually.

> - You should add an initramfs post transaction hook like in the regular
>   kernel [0] to avoid problems like described in #51818.

Thanks for the hint, will do.

> ring-daemon:
> - just a feeling but a description with 202 chars feels quite long :P

Is there a hard limit somewhere, maybe in the AUR?

Anyway, upstream has changed its description to a shorter one, so I used
that instead.  It's now "only" 130 chars.

> - you should use git+https:// instead of plain git:// even through the
>   CA world is a bit wonky it still authenticates the server and at the
>   very bare minimum adds confidentiality.

I don't like the "everything-over-HTTP(S)" approach in general, especially
when there is a dedicated protocol that works (yes, I know, this is basic ranting).

Assuming the git revision is identified by a commit hash, I see no value
in using HTTPS for authentication or verification.  I agree it is useful
however when building from a tag or a branch, as you correctly pointed out
for another package.

On the other hand, if one day the TLS certificate becomes invalid (expired
certificate, untrusted CA, etc), the package would fail to build.  I see
this as a significant drawback of using git+https://.

> pius
> - documentation, or hint to documentations inside .install files always
>   feels like the wrong place. If there is documentation in
>   /usr/share/doc/pius then people will find it.

I generally agree with this.  In this case, however, the suggested
configuration option is really needed on Arch when using the new Gnupg key
format, and this is not explicitely documented upstream.

I think I will send a patch upstream to fix the issue (auto-detect the
keyring format) and remove the .install file altogether with the next
release.

> ring-gnome-git
> - a VCS package should always provide its non-VCS package variant like
>   'ring-gnome'

Actually, the missing "provides" is intended.  The Ring components are
interdependent and get updated quite frequently, so at any given time
`ring-foo` and `ring-foo-git` are likely offer a different API/ABI.

More practically, when the "provides" was here, I had issues with AUR
users mixing -git and non-git ring packages and complaining of building
errors.

> libringclient-git
> - a VCS package should always provide its non-VCS package variant like
>   'libringclient'
> - If there is no strong reason to depend on a git variant, always depend
>   on the non VCS, in this case ring-daemon instead of ring-daemon-git

See the above comment on gnome-ring-git.

> - the pkgver() function doesn't sound specific enough, it just returns
>   a simple date without anything else (f.e. 20161110) which means
>   building on the same date can result in the same package version while
>   being built from quite different source states.

Good point, I can switch to the `git describe` method used by most of my
other git packages.

> udrawgraph
> - just a bit of style, but we have arch specific depends like
>   depends_x86_64 which looks better :P

Fixed.  This package long predates arch-specific depends.

> tsocks-ipv6
> - this looks like it should also provide tsocks as it just adds
>   additional v6 support

Indeed, fixed.

> coq-doc
> - the sources must be prefixed with the version as otherwise older
>   tarballs will "conflict". on top of that "stdlib.tar.gz" sounds
>   a bit too generic and may overlap with another package, conisder
>   also including the package name into the prefix to avoid such
>   situation.

Fixed.

> - sources that are not unique (like "/v$pkgver.tar.gz" from github)
>   should be prefixed with the package name (+ of cause pkgver) to
>   be unique. This is important if you configures shared SRCDEST to
>   avoid conflicts.

Fixed.

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

Fixed, I switched to a tarball.

> - every reference to $pkgdir should be put inside double-quotes in case
>   it contains spaces.

Fixed in all packages (hopefully).

Thanks,
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20161129/180bed1b/attachment-0001.asc>