On Tue, 14 Mar 2023 18:03:53 +0200 =?utf-8?Q?Samuli_Suonp=C3=A4=C3=A4?= <[email protected]> wrote: > > > On 14. Mar 2023, at 17.34, Luca Boccassi <[email protected]> wrote: > > > > Exactly, so the admin shouldn't install a package that in the > > description says: > > > > "Installing this package automatically overwrites /etc/resolv.conf and > > switches it to be managed by systemd-resolved." > > > > if that's not what they want to achieve. I agree that the > > /etc/resolv.conf interface is garbage, but there's nothing we can do > > about it, that's just how it works. > > This is the only way read-only images can be supported sanely. > > Why exactly is it necessary to overwrite /etc/resolv.conf at postinst, even if > the service will not and can not be started? > > Wouldn’t it make more sense to make the symlink at a later stage? For > Instance when the service is actually started?
No, because at that point /etc might be part of a read-only filesystem and thus it's too late. > There’s no point in having resolv.conf symlink to > /run/systemd/resolve/stub-resolv.conf when systemd-resolved is not running. Don't install it if you don't want it to run. I might accept a patch that switches to using tmpfiles.d, as long as the default is still to enable on install, and that taking a copy of the existing resolv.conf is also done, and that it is proven to work on a read-only image. That way it's easier to override it with a drop-in. I am not going to write and test such patch though, someone else needs to do it and send a MR on Salsa. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
