[aur-general] [Review Request] PKGBUILD for bumblebee-status
Hello, I'm the maintainer of a tiny small python project for i3 users (https://github.com/tobi-wan-kenobi/bumblebee-status). Turns out most of the people using it seem to be Arch users, so I'd like to provide an AUR package. Since I am not familiar with Arch myself, I'd kindly ask you to please have a look at the attached PKGBUILD just to make sure I'm not breaking anything for a majority of users (I will freely admit I have no clue what I am doing when it comes to building AUR packages). In particular, I am unsure about: * There is a git-based AUR already (https://aur.archlinux.org/packages/bumblebee-status-git/), the attached PKGBUILD is intended to be based on release-versions instead of the latest 'master'. Is it OK to use the same provides/conflicts in this case? * Since the sources are a git repo, I don't know how to provide any checksums for the package. Any insights on that would be much appreciated. Thank you very much for any input you can provide! Kr, Tobias
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
Input: https://ptpb.pw/7YEJ Output: https://ptpb.pw/-L5i On Sun, Sep 17, 2017 at 6:42 AM, Lex Black <autumn-wind@web.de> 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
-- Best, polyzen
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 <autumn-wind@web.de> 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
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. -- Morten Linderud PGP: 9C02FF419FECBE16
Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud <morten@linderud.pw>:
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 Sun, Sep 17, 2017 at 03:44:26PM +0200, Lex Black wrote:
Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud <morten@linderud.pw>:
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.
Sure, but you don't care for indirect dependencies. List them explicitly. -- Morten Linderud PGP: 9C02FF419FECBE16
On September 17, 2017 3:44:26 PM GMT+02:00, Lex Black <autumn-wind@web.de> wrote:
Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud <morten@linderud.pw>:
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
On 09/17/2017 03:55 PM, Levente Polyak wrote:
On September 17, 2017 3:44:26 PM GMT+02:00, Lex Black <autumn-wind@web.de> wrote:
Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud <morten@linderud.pw>:
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
Frankly, I didn't consider this. Thanks for pointing it out, I'm becoming increasingly aware that dependencies must be handled really carefully. I've updated the package to include python as mandatory dependency. Thanks, Tobias
Am 17. September 2017 15:55:37 MESZ schrieb Levente Polyak <anthraxx@archlinux.org>:
On September 17, 2017 3:44:26 PM GMT+02:00, Lex Black <autumn-wind@web.de> wrote:
Am 17. September 2017 15:07:48 MESZ schrieb Morten Linderud <morten@linderud.pw>:
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.
On Sun, 17 Sep 2017 12:09:02 +0200, Tobias Witek wrote:
* Since the sources are a git repo, I don't know how to provide any checksums for the package. Any insights on that would be much appreciated.
Hi, since you want to add "#commit=" as mentioned by Lex a simple $ man makepkg | grep -A3 geninteg -g, --geninteg For each source file in the source array of PKGBUILD, download the file if required and generate integrity checks. The integrity checks generated are determined by the checks present in the PKGBUILD, falling back to the value of the INTEGRITY_CHECK array in makepkg.conf(5) if these are absent This output can be redirected into your PKGBUILD for source validation using "makepkg -g >> PKGBUILD". should do the job. I've noticed a PKGBUILD for a git package that requires to IMO completely pointless generate checksums, instead of skipping them: https://aur.archlinux.org/packages/gtk-theme-united-archers-git/ Regards, Ralf
participants (6)
-
Daniel Capella
-
Levente Polyak
-
Lex Black
-
Morten Linderud
-
Ralf Mardorf
-
Tobias Witek