>> # AUR packages that I'll move to community > > Some notes on the proposed packages: > >> - bazelisk > > No offense, but the Github description made me think, "now I have bazel > and Golang, now I have three problems".
I'm not sure I follow you. Bazelisk is written in Golang, sure, but it's a thin executable that downloads an appropriate version of Bazel for any given workspace. I'm not sure what your familiarity with Bazel is as a contributor or user, but Bazelisk is pretty much the defacto "bazel" binary for most heavy users (companies, contributors, people who work in Bazel workspaces...). >> - 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. > 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. >> - copybara (`copybara-git`) >> - firebase-tools >> - google-appengine-go > > This depends on python2, something we want to get rid of :) I assume you only meant to include google-appengine-go here. Understandable, but python2 is an optdep, and I don't control upstream -- however, patching the source to remove the dependency on py2 altogether is something that's very feasible, and I'd glady do. >> - google-cloud-sdk >> - google-cloud-sdk-app-datastore-emulator >> - google-cloud-sdk-app-engine-java >> - google-cloud-sdk-app-engine-python >> - google-cloud-sdk-app-engine-python-extras > > These don't seem to be super popular packages, what would be the benefit > of having them in the repo? It seems that the Python runtime is python2 > something we actively want to get rid off. Except for google-cloud-sdk (which I'd argue is fairly popular), the component packages are additional utilities supporting the gcloud ecosystem. If the former is moved into community (which I believe makes sense, as it's a common tool used both in corporate and individual environments), then I personally think it makes sense to move the component packages into community as well. That said, it is possible to install the components from the gcloud command line tool, which could be enabled -- it's disabled to support using ALPM for the components. > Secondly why can't it install itself in the proper location > /usr/lib/python2.7/site-packages/$thing? I adopted the package and simply haven't made that adjustment, although it's one that I should. >> # Miscellaneous things I want to do >> >> - Take a look at the TU and maintainer workflows, and automate what can be >> automated (e.g. onboarding), with the goal of simplifying management of >> the >> Arch Linux ecosystem > > Cool, the current pain points are that archlinux.org is not on SSO, > mailman subscriptions aren't automated for Staff. Help is certainly > welcome there, so feel free to drop in #archlinux-devops with questions :) Will do! -- Ben Denhartog b...@sudoforge.com
