Hi Sam, On Thu, Jan 23, 2025 at 11:35:41AM -0700, Sam Hartman wrote: > "Debian's policy on mdns implementations: > > The default mdns implementation for Debian trixie is avahi-daemon. Other > packages must not provide an mdns resolver or publisher in their > default configuration."
Thank you for giving an example. It helps better me understand what you mean with setting policy, but I remain unconvinced that this poses a significant enough difference that we would not require a super majority as this policy has the same effect as overriding systemd maintainers. As a brief excursion into another CTTE bug, I could imagine a policy saying "The base-files package is responsible for managing the aliasing symbolic links /bin, /sbin and /lib*. No other package may create these with incompatible link targets." Again, this is phrased in a way of not singling out any package nor overriding a maintainer, but the net effect would be overriding the systemd maintainers. Why do you think that wrapping the text in a policy language frees us from the super majority requirement when it goes to the same effect? > I think that's probably a bad policy, but it seems fairly clear that if > Debian through the TC were to adopt such a policy it's clear that > systemd would be responsible for turning off mdns either at compile time > or through the default config files. Whether it is bad is debatable. The effect is practically indistinguishable from the (S) option in my last mail. The one thing I'd really add though is turning it into a time-limited policy, because we want to allow changing the default without necessarily invoking the CTTE again (as was necessary e.g. with repealing the file move moratorium). > If we think it is reasonable for systemd-resolved to provide MDNS > resolution when avahi-daemon is not installed, we could write a policy > that said avahi-daemon is our preferred implementation. Then we could > talk about how other implementations figure out whether they are the > most preferred implementation on the system and what their behavior > should be if they determine that they are not the most preferred > implementation on the system. (I'm imagining such a policy might push > the systemd maintainers toward a generator that generated runtime config > to turn off MDNS when avahi-daemon is installed, although I think you > could also write policy that pushed toward avahi-daemon generating a > drop-in. And here we are going into design work. Luca proposed that avahi-daemon disabled mDNS in resolved and this was contended by Laurent and Michael. If resolved were somehow noticing that it should disable mDNS when avahi-daemon is installed, much of the conflict would likely go away. I don't quite see yet how the generator (or other) approach is going to make it work in a practical way though. A generator cannot easily restart resolved and it would somehow have to manage it in the window of avahi-daemon's unpack and avahi-daemon.postinst. Finding such a solution (design work) has the potential of solving the conflict. > * The TC could be ruling on things like what our default > implementation is and on how packages handling the same interface > should interact. These matters truly do cross package boundaries and > if you phrase things that way it becomes obvious that the TC is > resolving a cross-package issue rather than stepping on a maintainer's > toes. As a result of your feedback, the most recent ballot proposal goes into this direction and states the default that we hopefully agree on. Thank you. > * You can phrase things in such a way that we (and our users) get a > decision even if the TC cannot come to a super majority. The TC would > need to at least come to a majority decision, but that may be easier. As detailed earlier, I remain unconvinced here. > * Things are not phrased in terms of overriding maintainers. Even that > can have some value depending on the personalities. It can also have the opposite effect of enabling it to be understood in a different way than intended. When things reach the CTTE, misunderstandings of some form often happened already. Being explicit reduces the risk of further conflict. A downside with being explicit and concrete is that some parameter may change over time and the decision may no longer make sense. Limiting the time of effect is a mitigation. Helmut
