On Mon, Feb 7, 2022, at 17:07, Brett Cornwall via aur-general wrote: > On 2022-02-07 13:33, Ben Denhartog via aur-general wrote: >>>> - buildozer >>> >>> This seems to not use the AUR bazelisk package for building, but a >>> release from github? Why doesn't it use the AUR package? >> >>I like to keep things simple for users. For AUR packages, that means trying >>to avoid depending on other AUR packages, as in my experience, most utilities >>that people use cannot resolve them, especially if they are building in a >>chroot. > > It's more important to be correct than convenient. Downloading the > builder is not appropriate here.
I have no issue with making this adjustment prior to moving the package into community. I'm recalling now that the change was initially made due to a `bazel` version mismatch between what was available in community and what was specified in the `bazelisk` repository; this is mentioned in the commit message that introduced this change [0]. As an alternative to doing this, patching the `.bazelversion` file is what I'd likely end up doing in community if/when the same issue occurs in the future (or simply hold updates while working on getting bazel updated [my understanding is that tensorflow is the main antagonist during major upgrades]). [0]: https://github.com/sudoforge/pkgbuilds/commit/15bc9c863219e7a3d2a94430ccd06210e86e6e04 >>> I myself try to avoid using "advanced" (or hard to read) bash in >>> PKGBUILDs such as here >>> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=buildozer#n44 >> >>Perhaps it is because I use parameter substitution in shell scripts >>regularly, I don't find that to be particularly hard to read. I understand >>that it could cause users who are not familiar with parameter substitution to >>scratch their heads, though, and think that's a fair comment and something >>that could be changed. > > This is not a matter of understanding but of readability. I'm with Ben > here: It's better to be clear than clever. I think you meant to say that you're with Jelle, correct? While I don't personally find any sort of difficulty in reading through parameter substitution, it seems like this is a sticking point, and that's perfectly fine. Refactoring that is straightforward and not something I'm going to contend with. -- Ben Denhartog b...@sudoforge.com
