[aur-general] Package review
Hi all, Looking for a bit of help with two new python packages I uploaded to AUR. Packages in question are python-root_numpy & python-hep_ml. So I think I've done the PKGBUILDs correctly, but when I run namcap on the packages I get warnings about unneeded dependencies included and specifically for hep_ml I get warning about not including any ELF files but not labelling it as 'any' platform. My issue is that I have included only dependencies that are listed by the package developers, but I still have namcap complaining. Also, I thought we weren't not supposed to label packages as 'any'. Or am I wrong? Thanks for the help. Regards, Konstantin
Hi Just a note for your last point. If there isn't any compiled component, which is architecture specific, in the package, then specifying 'any' is valid. See the Arch packaging standards in the wiki. Best regards Lex
On 10/13/2017 11:06 AM, Konstantin Gizdov wrote:
Hi all,
Looking for a bit of help with two new python packages I uploaded to AUR. Packages in question are python-root_numpy & python-hep_ml.
So I think I've done the PKGBUILDs correctly, but when I run namcap on the packages I get warnings about unneeded dependencies included and specifically for hep_ml I get warning about not including any ELF files but not labelling it as 'any' platform.
sed -i -e ... $(find -name '*.py') is terrible, see http://mywiki.wooledge.org/ParsingLs for why, as well as the proper way to do this. Please do not add pointless `msg "now I'm doing this thing that was obvious from context"` messages. As for namcap warning about unneeded dependencies, namcap is a rough hack and one of its big weaknesses is reliably determining what is actually a needed dependency. It can only really detect shared library dependencies, and assumes anything else, like for example python module dependencies, are unneeded... Take everything namcap says with a grain of salt, it can be useful to point out potential trouble spots but is hardly authoritative.
My issue is that I have included only dependencies that are listed by the package developers, but I still have namcap complaining. Also, I thought we weren't not supposed to label packages as 'any'. Or am I wrong?
If this were true, then why does "any" exist? https://wiki.archlinux.org/index.php/PKGBUILD#arch -- Eli Schwartz
sed -i -e ... $(find -name '*.py') is terrible, see http://mywiki.wooledge.org/ParsingLs for why, as well as the proper way to do this. Please do not add pointless `msg "now I'm doing this thing that was obvious from context"` messages. It's interesting that you point these things out as I took the template from the official repos for python-scikit-learn. Both the `sed` and `msg`
Hi Eli and Lex, lines are from there. I will change/remove them as per your suggestions. Thanks for clarifying `namcap` to me. One follow up question - in my `root` package namcap seems to be able to detect shell bangs in scripts ('#!/bin/csh' for example) and asks me to include csh/tcsh as dependency. At least I assumed that and only included it as optional dep. Does that mean instead, I actually have a binary dependency on CSH? As for the `any` I assumed it was deprecated after the x64 switch and the wiki was just not updated. I will label it correctly. Regards, Konstantin On Sun, Oct 15, 2017 at 6:56 AM, Eli Schwartz <eschwartz@archlinux.org> wrote:
Hi all,
Looking for a bit of help with two new python packages I uploaded to AUR. Packages in question are python-root_numpy & python-hep_ml.
So I think I've done the PKGBUILDs correctly, but when I run namcap on
On 10/13/2017 11:06 AM, Konstantin Gizdov wrote: the
packages I get warnings about unneeded dependencies included and specifically for hep_ml I get warning about not including any ELF files but not labelling it as 'any' platform.
sed -i -e ... $(find -name '*.py') is terrible, see http://mywiki.wooledge.org/ParsingLs for why, as well as the proper way to do this.
Please do not add pointless `msg "now I'm doing this thing that was obvious from context"` messages.
As for namcap warning about unneeded dependencies, namcap is a rough hack and one of its big weaknesses is reliably determining what is actually a needed dependency. It can only really detect shared library dependencies, and assumes anything else, like for example python module dependencies, are unneeded...
Take everything namcap says with a grain of salt, it can be useful to point out potential trouble spots but is hardly authoritative.
My issue is that I have included only dependencies that are listed by the package developers, but I still have namcap complaining. Also, I thought we weren't not supposed to label packages as 'any'. Or am I wrong?
If this were true, then why does "any" exist?
https://wiki.archlinux.org/index.php/PKGBUILD#arch
-- Eli Schwartz
On 10/16/2017 05:50 AM, Konstantin Gizdov wrote:
Hi Eli and Lex,
sed -i -e ... $(find -name '*.py') is terrible, see http://mywiki.wooledge.org/ParsingLs for why, as well as the proper way to do this. Please do not add pointless `msg "now I'm doing this thing that was obvious from context"` messages. It's interesting that you point these things out as I took the template from the official repos for python-scikit-learn. Both the `sed` and `msg` lines are from there. I will change/remove them as per your suggestions.
You've learned an interesting truth. :D Packages in the official repos can do some pretty gross and silly things. Just because someone is a TU doesn't necessarily mean they follow best-practice bash style. You'll also see a fair number of packages which do not quote $srcdir or $pkgdir, which can generally be gotten away with simply because repo packages are built using makechrootpkg which uses the /build directory in a chroot. It still doesn't mean it is "okay" to use unquoted $srcdir and $pkgdir in a PKGBUILD...
Thanks for clarifying `namcap` to me. One follow up question - in my `root` package namcap seems to be able to detect shell bangs in scripts ('#!/bin/csh' for example) and asks me to include csh/tcsh as dependency. At least I assumed that and only included it as optional dep. Does that mean instead, I actually have a binary dependency on CSH?
Could be namcap can also detect shebangs as well, which is better than I thought to be honest. It is obviously a hard dependency for using those scripts, so if those scripts are optional then list an optdepends, otherwise list a depends.
As for the `any` I assumed it was deprecated after the x64 switch and the wiki was just not updated. I will label it correctly.
... okay. Just to be clear, PKGBUILDs and makepkg have rules and definitions which are independent of which arches are supported by archlinux.org at the time the PKGBUILD is first written. Keep in mind that pacman is developed *by* Arch Linux, but it is not exclusive to Arch Linux. There are several derivative distros which use pacman, some of which also make use of the AUR, and this includes both Arch Linux ARM and https://www.archlinux32.org (which will continue 32-bit support after the official deprecation). You can also use pacman as one of many optional package management schemes with Linux From Scratch. -- Eli Schwartz
participants (3)
-
Eli Schwartz
-
Konstantin Gizdov
-
Lex Black