The future of /etc/doas.d

Follow-up from !46996 (closed)

Show rant

In 0d85d8f3, a downstream patch was added to doas to add support for reading multiple config files from /etc/doas.d. This was pushed directly to aports without review of any kind and without my approval or input. I am the maintainer of this package, and I have not been treated with any particular degree of respect in this role, or, to be honest, in my various Alpine-related contributions and responsibilities as a whole.

I may not be an Alpine committer (why? who knows), but I am the maintainer of this package and the fact that it's in main and part of stable Alpine releases does not, according to Alpine policy, and common sense, change the fact that I am responsible for it. If I should not be permitted this responsibility, then should non-committers even be allowed to maintain packages in main? Anyone who views my continued participation in this package as a nuisance should forward this question to the TSC; or my participation in Alpine generally, to the Council.

As for now, I am going to assert the privileges entitled to me by the maintainer policy. I am in charge of this package. Nevertheless, I will strive for compromise and aim for a resolution which is minimally disruptive to users. We can make breaking changes, every release tends to include a few -- and I will make no proposal to backport any breaking change to stable releases.

Alpine ships a downstream doas patch adding support for a configuration directory, /etc/doas.d, from which multiple config files can be sourced from packages/etc. I was never fond of this patch to begin with, and 2 years later it seems clear that this is unlikely to make its way upstream. I am not particularly interested in hosting a non-trivial downstream feature additions in this package indefinitely.

This feature is depended on, internally, by fourfive packages:

• community/apk-deploy-tool
• community/apt-dater-host
• community/cloud-init
• community/repmgr
• main/nagios-plugins

It's unclear how many downstream users require this functionality, a survey might be conducted by anyone who feels strongly about it.

I propose a few paths forward for discussion:

1. Drop it unceremoniously and cat together existing doas.d files in the post-install with a warning
2. Convince doas upstream to take the (improved) patch
3. Replicate the functionality in a separate doas-multiconf package, which either:
   • Supports a post-update script, as proposed in tsc#1 (closed), which builds /etc/doas.conf
   • Hosts a patched doas and conflicts=doas, ideally with @jirutka's improved patch that upstream for some reason was skeptical of
4. Let users who rely on this functionality use sudo out of community. It's designed to support more complex use-cases anyway, and doas is meant to be simple.

In the third case I would like this to land in community, which would imply moving nagios-plugins to community or finding an alternate approach.

Thoughts?