Arch Linux User Repository

These lines aren't particularly complex, but a reviewer still has to pause and consciously determine that they're inconsequential, and that's a cost that could simply be avoided. Complex build steps are sometimes unavoidable; this isn't one of those cases.

It's also worth noting that the official package maintainers manage perfectly well without any of this.

Ultimately it's your packages and your call. I just think the PKGBUILD would be easier to audit without them, and wanted to make that case.

Are you referring to my other packages with that citation? Because this PKGBUILD doesn't use any custom variables or functions. And sure, I use them even when packages could be built without them. But I only use them to solve actual problems and to adhere to general software development good practices.

I'm also familiar with the ShellCheck recommendation for PKGBUILDs. However, I've established why the recommendation is flawed in my previous comment and I haven't come across any real counterargument. I judge the solutions based on their correctness and performance before their conventionality.

Regarding confusing lines, I totally agree. However, I'm not aware of any really confusing lines in this PKGBUILD. The reality is that in order to be able to audit PKGBUILDs properly, you have to understand Bash. There's no way around it. And I use just plain Bash. Nothing crazy, nothing exotic. But even if somebody doesn't understand the purpose of the shebang or the colons followed by parameter expansion, they should utilize their Bash knowledge (and perhaps a search engine/LLM query) to quickly realize that these lines aren't consequential to the user.

To me, it seems like you're arguing for the sake of uniformity with the rest of the ecosystem, which is understandable. However, I don't subscribe to the idea that uniformity is more important than quality.

To cite from the package etiquette:

Do not introduce new variables or functions into PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables and functions used in makepkg itself.

For using ShellCheck, the PKGBUILD article recommends:

Use shellcheck(1) to check PKGBUILDs for common scripting mistakes. See also SC2034, SC2154 and SC2164:
shellcheck --shell=bash --exclude=SC2034,SC2154,SC2164 PKGBUILD

Especially these days with all the attacks on the AUR, I don't think it's wise to add confusing lines that make it harder for users to review the PKGBUILD.

@gwuensch, why? AFAIK it doesn't pose any problems, since the PKGBUILD isn't executable. It's used here to inform ShellCheck about the execution environment, so that it can lint the script properly.

@Ordoviz, no, it's not useless. See my response to @gwuensch above. Disabling rules globally is generally an anti-pattern, as it may suppress relevant findings. Also, I see no good reason to make the PKGBUILD less self-contained by defining the shell externally, and in doing so, dropping -e, which does influence the findings.

I'm open to suggestions, but they have to actually improve something and you may need to explain to me how your suggestions actually do that. Blanket statements are gonna trigger no action on my side.

Yeah, the shebang is useless. If you have a directory for all your PKGBUILDs (say ~/aur), you can silence shellcheck by creating ~/aur/.shellcheckrc with

shell=bash
disable=SC2034,SC2154,SC2164

The PKGBUILD should not have a Shebang line (#!/bin/bash -e).

Regarding the problem with pasta, it really seems like a bug in passt itself that should be resolved in the next release. See https://github.com/rootless-containers/rootlesskit/issues/591.

@the-k, thank you for the extra details. I missed gvisor-tap-vsock in the upstream release notes, but I've switched to it now and it works fine for me.

cat > ~/.config/systemd/user/docker.service.d/override.conf << 'EOF'
[Service]
Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=gvisor-tap-vsock"
EOF

reinstalling slirp4netns doesn't change anything. You probably didn't have it installed at all (which would be the case if it was a fresh install of this package), or the installed version was ancient, corrupted or your setup somehow overrode the default configuration.

The reason slirp4netns was removed is that I use aconfmgr-git (a configuration manager for Arch, similar to the NixOS approach), and since it wasn't listed as an explicit dependency, it got removed during aconfmgr apply.

@stasadev, normally, reinstalling slirp4netns doesn't change anything. You probably didn't have it installed at all (which would be the case if it was a fresh install of this package), or the installed version was ancient, corrupted or your setup somehow overrode the default configuration.

I can reproduce the problem with pasta:

[rootlesskit:parent] error: failed to setup network &{logWriter:0x2165643aae50 binary:pasta mtu:65520 ipnet:0x2165642fca20 disableHostLoopback:true enableIPv6:false ifname:tap0 infoMu:{w:{_:{} mu:{state:0 sema:0}} writerSem:0 readerSem:0 readerCount:{_:{} v:0} readerWait:{_:{} v:0}} implicitPortForwarding:true info:<nil> feat:0x2165643aef1f}: pasta failed with exit code 1:
--stderr will be dropped soon
Dual stack forward, but IPv6 not enabled
Unable to add rule TCP [*]:1-32767  =>  1-32767  (best effort) (auto-scan)
[rootlesskit:child ] error: EOF

However, this seems to be a bug in passt/RootlessKit/Docker, not in this package.

The reason why I moved slirp4netns to optional dependencies is that Docker now supports gvisor-tap-vsock driver, which is embedded in RootlessKit v3, and Docker falls back to it when no other suitable driver is available. So technically, this package no longer requires any external driver and this package works exactly as the upstream intends. I understand that this UX isn't ideal in your situation, but since PKGBUILD doesn't have anything akin to Debian's Recommends, I don't have much choice if I don't wanna force a potentially useless dependency upon all users.

slirp4netns got moved to an optional dependency in 29.5.0-1. If you don't explicitly set DOCKERD_ROOTLESS_ROOTLESSKIT_NET, the script uses the first available backend.

I already had passt installed, so it picked pasta, which failed for me with:

Cannot connect to the Docker daemon at unix:///run/user/1000/docker.sock. Is the docker daemon running?

I had to reinstall slirp4netns and force it as default to avoid issues if the upstream script or packaging changes:

cat > ~/.config/systemd/user/docker.service.d/override.conf << 'EOF'
[Service]
Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=slirp4netns"
EOF