Sparronator

> It is very possible I defined the capabilities set wrong. I wasn't totally sure of the syntax, and tried working it out from some other scripts, but very well...

I can confirm that changing the capabilities to be all prefixed with `^` fixed my issue. I'll create a PR shortly with the above change (with appropriate credit).

> This is not a default Alpine package. `doas` is installable from the `main` Alpine repository (see [here](https://pkgs.alpinelinux.org/package/v3.22/main/x86_64/doas)), and so should be able to replace `sudo` in the `pihole-meta` package....

> I think we could make `doas` and `doas-sudo-shim` a dependency of the alpine package. [@Sparronator9999](https://github.com/Sparronator9999) Do you want to PR that change? Sure thing. Note that I haven't actually...

> It's fine to do so before filing the PR ;-) How do I edit my `pihole-meta` to use `doas` and `doas-sudo-shim` instead of `sudo`? As stated originally I can't...

> I'm not sure how to do it best without removing the package first and creating a local package afterwards. But this seems unnecessary cumbersome. I pushed the change to...

> I'm not sure if alpine allows downgrading packages, if not, the meta-package need to be removed first before downgrading. I just went back to `master`, and the package downgraded...

I had some spare time tonight, so I've made a PR which changes the install script to check which privilege escalation command is installed, and use that one (with `sudo`...

> An alternate approach (linked PR) is to not mandate any particular elevation command even on a distro by distro basis, by instead using runuser to drop to the pihole...

> Yes it kind of can, and I considered adding it but as you say it's not really the favoured approach any more. You can for example `su -c 'basic-install.sh'...