Re: [aur-general] TU application for sudoforge
Il 29/01/22 23:27, Ben Denhartog via aur-general ha scritto: > # AUR packages that I'll move to community [...] - kind (`kind-bin`) Hello, kind is open source and hosted on github, is there any problem compiling it from source?
Re: [aur-general] TU application for sudoforge
No, it's pretty straightforward, but note that being "closed source" and/or "difficult to compile from source" are not qualifying factors for determining whether or not a package should be moved to community. I'm not arguing that `kind-bin` _should absolutely_ be moved to community, simply that the parameters you're asking about are not pertinent to whether or not it is. -- Ben Denhartog b...@sudoforge.com On Thu, Feb 17, 2022, at 10:41, Fabio Loli via aur-general wrote: > Il 29/01/22 23:27, Ben Denhartog via aur-general ha scritto: > > > # AUR packages that I'll move to community > [...] >> - kind (`kind-bin`) > > Hello, kind is open source and hosted on github, is there any problem > compiling it from source?
Re: [aur-general] TU application for sudoforge
On 2022-02-17 11:59, Ben Denhartog via aur-general wrote: No, it's pretty straightforward, but note that being "closed source" and/or "difficult to compile from source" are not qualifying factors for determining whether or not a package should be moved to community. I'm not arguing that `kind-bin` _should absolutely_ be moved to community, simply that the parameters you're asking about are not pertinent to whether or not it is. To be honest, I'm not sure what you're arguing here. Are you saying that software being closed source or with significant compiling difficulty would have no bearing on their inclusion into [community]. Are you saying that you would rather bring in binary releases into the repositories? (BTW, please do bottom post on Arch mailing lists :)) signature.asc Description: PGP signature
Re: [aur-general] TU application for sudoforge
On 2022-02-07 16: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 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. Do you have any response to these statements? I'm curious to hear your thoughts. signature.asc Description: PGP signature
Re: [aur-general] TU application for sudoforge
On Thu, Feb 17, 2022, at 14:22, Brett Cornwall via aur-general wrote: > On 2022-02-17 11:59, Ben Denhartog via aur-general wrote: >>No, it's pretty straightforward, but note that being "closed source" and/or >>"difficult to compile from source" are not qualifying factors for determining >>whether or not a package should be moved to community. >> >>I'm not arguing that `kind-bin` _should absolutely_ be moved to community, >>simply that the parameters you're asking about are not pertinent to whether >>or not it is. > > To be honest, I'm not sure what you're arguing here. Are you saying that > software being closed source or with significant compiling difficulty > would have no bearing on their inclusion into [community]. Are you > saying that you would rather bring in binary releases into the > repositories? Ah, I get the issue. Yes, the AUR package is a binary package; no, if it were moved to community I would not be downloading the release binary but instead building from source in accordance with the Go Package Guidelines [0]. I replied off-the-cuff while in a meeting and completely glossed over that aspect of the discussion. [0]: https://wiki.archlinux.org/title/Go_package_guidelines > (BTW, please do bottom post on Arch mailing lists :)) Good catch :) -- Ben Denhartog b...@sudoforge.com
Re: [aur-general] TU application for sudoforge
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
