Comment 13 for bug 1918141

> This isn't a Ubuntu decision - upstream of the package/functionality goes this way, so if challenged one should challenge it there.

I disagree. This is entirely a question of how we integrate between services. The distribution is where that integration happens, and users expect consistency of integration from the distribution. This is the point of packaging. Where there is a conflict, consistency here should be across different packages in the distribution, rather than between individual packages and their upstreams. So we should figure out what best practice should be across our package archive first.

> I remember a few of the old incarnations of this discussion, but it already has become a (use)case-by-case decision throughout various packages and services.

Even more reason to seek to develop a best practice then, rather than continue to exacerbate a problem that might already exist.

If it's decided that network-online.target should normally be provided by default by any package that provides a service that (might be configured/always) depend on a network service, then that's fine, the change in Hirsute will be correct, and we can continue to change packages when this issue is inevitably brought up again. But that should be a deliberate choice we make, not one made on a piecemeal basis only considering one use case at a time. Because consistency across the distribution matters for user expectations and a good user experience.

To be clear, I'm not presupposing the answer here; I just want this properly considered and a consistent decision made that considers the distribution as a whole.

> For this I honestly see no risks of regressions for nfs-server.

As Christian noted, there's a difference here in changing this for the future, and changing this in existing stable releases. There's a relatively low downside if we don't change this in existing stable releases. Users aren't blocked: they just need to configure their dependencies according to their local requirements. This is relatively easy and already explained here. The downsides in not making the change is: Users configuring a service for the first time will have to find an issue and discover the bug. The downside in making the change is: We're changing behaviour for users who've already configured the service, which might break them depending on their specific local setup.