Hey, On Fri, Jul 13, 2018 at 3:45 PM, Eli Schwartz via aur-general <aur-general@archlinux.org> wrote:
Very few people are "good enough" when I really get on a roll... I generally consider it sufficient that people learn from my critiques, fix them promptly, and incorporate that feedback into further efforts.
The only thing that really startled me, actually, were the packages which build ELF binaries but were marked as "any" packages.
I understand. To be fair in AUR we only build the package for our architecture, so that never seemed like a red flag until you pointed it out. But now I see how important it is to have a proper arch field :)
As with the other unquoted variables issues... it may have been committed 11 days ago but my git pull from when I started my review did not have that yet, perhaps you never pushed it?
I did say some of those issues were already fixed before I sent off my email -- I did not go back to re-analyze the packages I'd already looked at based on the fixed versions. ;)
That was probably it, sorry.
Then I would guard this by
if [[ $CARCH = x86_64 ]]; then do_64_bit_things else do_32_bit_things fi
Don't ignore unexpected errors, if there's no lib64 folder on x86_64 builds then something went wrong and either should be fixed, or old workarounds should be removed -- either way using || true, means you'll never know.
I'll use Michael's approach but thanks for pointing this out, it will probably be useful in similar situations that can't be resolved in cmake.
nodejs packaging confuses me incredibly. I've only got one package which uses nodejs, and this is what I do: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=rapydscript-ng-git#n3...
I build it in build() and then I manually cp things to $pkgdir and write my own symlink for /usr/bin scripts. It seems to work okay...
I agree. That's a good approach but I think mine is a bit cleaner, ahah :)
For your three electron apps, you get to have fun, because electron is fun! Haha, I lied, it's not fun at all.
They're basically always bin packages because electron. Debundling is complicatedly weird, but I've successfully done so for e.g. community/keybase-gui. When I get around to it I need to create a new wiki page documenting how to handle this correctly...
I definitely understand if you've got no will to make proper non-bin packages, that being said it would be neat if you could do so anyway since having dozens of outdated, insecure copies of prebuilt electron (thanks, electron devs!) is pretty dreary and also wasteful of disk >space.
That is something I'll keep in mind this summer. I really dislike electron because I don't see the point of packaging a full runtime with each app (!!) so I am not really motivated to maintain non-bin electron packages. I might try to do it if I have spare time, that could turn out to be a fun puzzle. Thanks, Filipe Laíns