Comment 11 for bug 1918141

Hi Robie - I remember the old discussions and the tag, In this particular case I think it is somewhat special because.

a) This isn't a Ubuntu decision - upstream of the package/functionality goes this way, so if challenged one should challenge it there. So if we want to we should do it there.

b) This one is also different as it isn't a service that your system "consumes" like root-iscsi or anything like it - there we'd get "my boot hangs". But in this case this exists to "provide" services to others. I know that there are others that have problems, e.g. things that fail to bind on an interface as they reject to listen to netlink to "bind later once available". But if this ends up as case-by-case decision

c) 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. Some clearly work best with After=network-online, some are clearly degraded with it - and sadly there are some in between which are either way depending on the sourrounding HW/Setup/Use-Case. Have a look at the growing list of packages that have implemented it that way - https://codesearch.debian.net/search?q=After.*network-online&literal=0

Based on that IMHO I think:
- the change for Hirsute is right
- it might be right to challenge it (to be sure about this particular case), but then let us do so at upstream nfs-utils
- I agree that for an SRU the potential regressions might be too much and there users can configure it accordingly