Packaging policy discussion:

Thadeu Lima de Souza Cascardo cascardo at
Thu May 13 11:53:28 UTC 2021

On Wed, May 12, 2021 at 05:52:07PM +1000, Christopher James Halse Rogers wrote:
> Hello everyone,
> There's an nfs-utils SRU¹ hanging around waiting for a policy decision on
> use of the systemd unit dependency. I'm not an
> expert here, but it looks like part of my SRU rotation today is starting the
> discussion on this so we can resolve it one way or another!
> I am not an expert in this area, but as I understand it, the tradeoff here
> is:
> 1. Without a dependency on there is no guarantee
> that the network interface(s) will be usable at the time the nfs-utils unit
> triggers, and nfs-utils will fail if the relevant ntwork interface is not
> usable, or
> 2. With a dependency on nfs-utils will reliably
> start, but if there are any interfaces which are configured but do not come
> up this will result in the boot hanging until the timeout is hit.
> In mitigation of (2), there are apparently a number of default packages
> which already have a dependency on, so boot
> hanging if interfaces are down is the status quo?
> The obvious thing to do here would be to follow Debian, but as far as I can
> tell there is not currently a Debian policy about this - the best I can find
> is an ancient draft of a best-practises-guide² suggesting that pacakages
> SHOULD handle networking dynamically, but if they do not MUST have a
> dependency on
> As far I understand it, handling networking dynamically requires upstream
> code changes (although maybe fairly simple code changes?).
> It seems unlikely that, whatever we decide, we'll immediately do a full
> sweep of the archive and fix everything, so it looks like our choice is
> between:
> 1. The long-term goal is to have no dependencies
> in default boot (stretch goal: in main). Whenever we run into a
> package-fails-if-network-is-not-yet-up bug, we patch the code and submit
> upstream. Over time we audit existing users of
> and patch them for dynamic networking, as time permits.

I think there will be exceptions, and as long as they are documented, they
should be fine.

Take kdump-tools, for example. After a system crash, it will reboot into a mode
that collects a memory dump and reboot. Some times, it is configured to send
the dump through the network. If the network does not come up after some
timeout, it should just reboot. And systemd machinery is leveraged to
accomplish that. As long as that is what is happening and it's documented, I
don't see a reason to not use

Caveat: I am not claiming this is working exactly as described here, and there
are always corner cases that we try to fix. Just pointing out an example that
uses and that maybe we should just use the
implemented machinery instead of reimplementing it ourselves.


> 2. We don't expect to be able to reach no
> dependencies in the default boot, so it's not a priority to avoid them.
> Whenever we run into a package-fails-if-network-is-not-yet-up bug, we add an
> dependency.
> Option (1) seems to be the technically superior option (and is recommended
> by systemd upstream³), but appears to require more work. I have limited
> insight into how much work that would be; someone from Foundations or Server
> probably needs to weigh in on that.
> Option (2) seems to be formalisation of the status-quo, so would seem to be
> less work.
> Let the discussion begin!
> ¹:
> ²:
> ³:
> -- 
> ubuntu-devel mailing list
> ubuntu-devel at
> Modify settings or unsubscribe at:

More information about the ubuntu-devel mailing list