[pkg-go] Bug#1020691: debos should depend on systemd-resolved

Christopher Obbard chris.obbard at collabora.com
Mon Oct 24 15:55:43 BST 2022


On Mon, 2022-10-24 at 20:00 +0700, Arnaud Rebillout wrote:
> 
> On 24/10/2022 17:34, Christopher Obbard wrote:
>  
> > I have proposed[1] to check if systemd-resolved is available at
> > runtime, to at least let users know *why* name resolution doesn't
> > work
> > inside their fakemachine over letting the user debugging it
> > themselves.
>  
> > [1]: https://github.com/go-debos/fakemachine/pull/115
> That's nice! I thought of it as well, and I was wondering if systemd-
> resolved (and possibly other services) should be listed under
> Requires= instead of Wants= (talking about
> https://github.com/go-debos/fakemachine/blob/main/machine.go#L288).
> But then, I noticed commit 4c60b85a8302f0fa544adae73f0649726034711c,
> and why using Wants= is the intention. So your approach works better.

That's been merged into Fakemachine now.


> > Perhaps we should add systemd-resolved to Suggests in
> > debos/fakemachine? Adding it as a Depends/Recommends would break
> > users
> > who have some other package on their machine handling name
> > resolution.
> > 
> > @Arnaud, how does that sound?
> Well, I'm not sure for the packaging part. If fakemachine needs
> systemd-resolved to be functional, then it should be a Depends.
> That's what Depends is for.
> At a quick glance, there's no reverse dependencies of fakemachine /
> debos. So the only users that would be surprised by the change are
> the ones who installed it explicitly, so we can assume those are
> technical users and they'll find their way? But then, what if there
> are some installations on servers (think builders), and the upgrade
> breaks the name resolution? Not a nice surprise.
> OTOH, an error message saying that "/lib/systemd/systemd-resolved is
> missing", plus a Suggests: systemd-resolved, both together gives a
> strong hint regarding what should be done. It sounds sensible as
> well.
> Sorry, that's not really a clear answer :) 
> Best,

I'm more leaning on just adding it as a direct Dependency to the Debos
package and seeing if anyone moans...



More information about the Pkg-go-maintainers mailing list