Hi, thanks a lot for the quick responses - and in particular for the improved version (and for the checksum improvements in the other mail)! I will look into adding it to AUR with the suggested improvements right away. With a community that friendly, I'm now seriously considering switching to Arch :-) Thanks! Tobias On 09/17/2017 01:48 PM, Daniel Capella via aur-general wrote:

Input: https://ptpb.pw/7YEJ Output: https://ptpb.pw/-L5i

On Sun, Sep 17, 2017 at 6:42 AM, Lex Black wrote:

...

Hi

Some issues I noticed: In this case you should remove the conflict and the provides line. And the _pkgname variable does not differ from pkgname so it should be removed too. The prefixed v in the pkgver should be removed. Regarding downloading the source there is a Arch-Wiki page for VCS packages. Three choices regarding this specific case. You can directly download the tar archive tied to the tag, append the current source with #tag=v${pkgver} or with #commit= followed by the commit hash tied to the tag. The latter being preferred IIRC to avoid the issue with retagging. If doing the first, the source line should be prefixed with ${pkgname}-${pkgver}:: to make the file name of the downloaded tar archive unique.

All three make the git command usage in package() obsolete.

Best regards Lex

Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud :

On Sun, Sep 17, 2017 at 07:48:24AM -0400, Daniel Capella via aur-general wrote:

...

Input: https://ptpb.pw/7YEJ Output: https://ptpb.pw/-L5i

Missing "python" in the depends array.

Any specific reason? It is indirectly covered through the dependencies.

On September 17, 2017 3:44:26 PM GMT+02:00, Lex Black wrote:

Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud :

...

On Sun, Sep 17, 2017 at 07:48:24AM -0400, Daniel Capella via aur-general wrote:

...

Input: https://ptpb.pw/7YEJ Output: https://ptpb.pw/-L5i

Missing "python" in the depends array.

Any specific reason? It is indirectly covered through the dependencies.

Because technically it's a very direct first level dependency. It's quite unlikely that a first level python lib dependency will ever not depend on python itself, however it is a quite bad trend to remove any first level dependency just because another one covers it on the second level. For c libs it is also easier to fetch things that need a rebuild rather then grepping for sonames that are linked against it. Either way, all first level dependencies should always be defined, personally I call anything else a bad practice. Of course one could easily fix a missing first level dependency when another lib drops it, however that's not the point, it still remains technically incorrect. Cheers, Levente

Am 17. September 2017 15:55:37 MESZ schrieb Levente Polyak :

On September 17, 2017 3:44:26 PM GMT+02:00, Lex Black wrote:

...

Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud :

...

On Sun, Sep 17, 2017 at 07:48:24AM -0400, Daniel Capella via aur-general wrote:

...

Input: https://ptpb.pw/7YEJ Output: https://ptpb.pw/-L5i

Missing "python" in the depends array.

Any specific reason? It is indirectly covered through the dependencies.

Because technically it's a very direct first level dependency. It's quite unlikely that a first level python lib dependency will ever not depend on python itself, however it is a quite bad trend to remove any first level dependency just because another one covers it on the second level. For c libs it is also easier to fetch things that need a rebuild rather then grepping for sonames that are linked against it. Either way, all first level dependencies should always be defined, personally I call anything else a bad practice. Of course one could easily fix a missing first level dependency when another lib drops it, however that's not the point, it still remains technically incorrect.

Cheers, Levente

Some valid points. Thank you for the explanation. I will keep it in mind for future updates of my packages.