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#n38 > >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
signature.asc
Description: OpenPGP digital signature