[aur-general] TU application for sudoforge

Ben Denhartog ben at sudoforge.com
Thu Feb 17 21:53:02 UTC 2022


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
  ben at sudoforge.com


More information about the aur-general mailing list