Comment 5 for bug 1649931

On Thu, Dec 15, 2016 at 10:27 PM, Brian Murray <email address hidden> wrote:

> How is this fixed in the development release?
>

There is an upstream resolvconf bug that addresses that package portion:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847440

> Also the having a "Regression Potential" of low just because not a lot
> of people use the service is wrong. A bad change could still horribly
> impact the users of the software, regardless of how many users there
> are.
>

I don't disagree (that saying few folks impacted means low).

This portion was split out from the previous systemd SRU

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636912

in which the changes were classified in the same way, so I was coping over
the assessment done by pitti and Foundations with which I agree.

I'd be happy if someone else could comment on whether they disagree with
the assessment.

IMO the risk is low:

The changes involve running resolvconf.service earlier (which sets an
inotify watch) and
does not regress anyone AFAICT.

Asking that DNS services (systemd-networkd-resolvconf-update.service) to
run before
network-online.target vs. (how it is today) running after
network-online.target is reach
 also has low regression potential since _nothing_ requiring networking
should
run before systemd reaches network-online.target anyhow.

These potential users would already be broken since the units don't
currently
ensure that resolvconf (when using networkd instead of
networking.service/ifupdown)
runs to completion before reaching network-online.target.

>
> ** Changed in: resolvconf (Ubuntu)
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1649931
>
> Title:
> systemd-networkd needs to ensure DNS is up before network-
> online.target
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/resolvconf/+
> bug/1649931/+subscriptions
>