I have installed dnscrypt-proxy to look into its documentation. I were using unbound+dnssec-trigger and wanted it to continue. But after a reboot my configuration were broken and VPN redirection did not work. I have found that happened because dnscrypt-proxy has a custom way to auto-enable itself on installation. I do not think this is allowed by packaging guidelines. Reproducible: Always Steps to Reproduce: 1. dnf install unbound dnssec-trigger 2. dnf enable --now dnssec-triggerd 3. dnf install dnscrypt-proxy 4. reboot Actual Results: my explicitly configured unbound has failed to startup, because there is different service listening on the same port already. I have never chosen to replace that by dnscrypt-proxy. Expected Results: The service is enabled only manually, by usual configuration via systemctl: systemctl enable --now dnscrypt-proxy Fedora allows auto-enabled services only when they do not modify other services. That does not happen directly, but by listening on common domain port on 127.0.0.1 it effectively does. If it used alternative localhost address it might be okay. But it must not as it is now. This service has not a FESCo ticket required to be enabled by default: https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/90-default.preset I do not think it passes guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_enabling_services_by_default It also does not use systemd macros, which I think it should use: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
Yup, this needs to be fixed. This package was recently orphaned and I picked it up, will try and get this sorted out on the next update (hopefully) soon.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.