Todd Zullinger writes:
Kevin Fenzi wrote: [...snip loads of useful information...] > So, I think if you: > > disable systemd-resolvedTo that end, the change proposal¹ when systemd-resolved was enabled by default (F33) contains an example of how to ensure the service remains disabled -- which would avoid the situation Sam had where it got installed due to a dependency chain and then started because the preset enables it.
Well, if it was installed due to a dependency, then it would be reasonably expected that whatever declared it as a dependency required a working systemd-resolved. After all, why declare it as a dependency, otherwise?
sudo bash -c 'mkdir -p /etc/systemd/system-preset && echo "disable systemd- resolved.service" >/etc/systemd/system-preset/20-systemd-resolved- disable.preset'I used that at the time and have not had systemd-resolved start up on any updates or upgrades (so far and IIRC).
And doing that would presumably break whatever pulled in systemd-resolved, due to a bone-fide dependency on a working systemd-resolved.
So, either something needed systemd-resolved, or not. If it did not really need it, it should not've been declared as a dependency. If it did, then a preset that disables systemd-resolved would break something.
This whole preset mechanism seems like a workaround for a functional or a design gap.
pgplcIA51B8rE.pgp
Description: PGP signature
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
