Bug#1032937: breaks upgrades if systemd-resolved can't run

[Luca Boccassi]

On Tue, 14 Mar 2023 18:03:53 +0200 =?utf-8?Q?Samuli_Suonp=C3=A4=C3=A4?=
<suonpaa at diurnalis.fi> wrote:
> 
> > On 14. Mar 2023, at 17.34, Luca Boccassi <bluca at debian.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230314/d1ecddb7/attachment.sig>