On Mon, 8 May 2023 at 16:39, Sam Hartman <hartm...@debian.org> wrote: > > >>>>> "Luca" == Luca Boccassi <bl...@debian.org> writes: > > Luca> It has come to my attention that there is one package in > Luca> Debian using dpkg-divert to mask a systemd configuration file > Luca> (an udev rule). Speaking as one of the maintainers, both > Luca> upstream and downstream, I find this greatly undesirable for > Luca> several reasons that I will outline later. Hence I would like > Luca> to propose explicitly mentioning that dpkg- divert must not be > Luca> used for systemd configuration files (units, rules, etc), and > Luca> instead the supported workflow (drop-ins, masking, etc) must > Luca> be used, both by packages and administrators. > > First, I thought there was already a prohibition about one package > mucking with another package's configuration. > In many cases it sounds like it's already against policy for one package > to change the default systemd or udev configuration--at least for > packages in the archive. > (I am skepticle that amazon-ec2-utils complies with policy in general). > > > In cases where the change being made is permitted by policy, I think you > have made a compelling case to vastly prefer the native systemd and udev > mechanisms to dpkg-divert. > I don't think that your case is strong enough to forbid dpkg-divert. > > As far as I can tell reading your reasoning, dpkg-divert *works fine*. > It just gives surprising results to someone coming from the systemd > universe. > > But consider a package that diverts several resources, several of them > systemd and several of them not systemd. > The maintainer might legitimately want to use the same mechanism for all > the overriding/masking so that systemd resources and non-systemd > resources were handled the same. > > There's a real trade off there, and we generally leave those to > maintainers. > > So, I'd support policy advice (ENCOURAGED) rather than policy > requirements (MUST) in this case. > > I do think that if a maintainer violates this advice without a good > reason, important is a more appropriate bug severity than wishlist, but > unfortunately we don't have a good way to specify that in policy > language. > > I would not support policy recommendation language (RECOMMENDED/SHOULD) > because that has a connotation that failing to follow the recommendation > is always a bug, and I don't think that's true here.
The problem is that when there are udev/systemd bugs they get directed to the systemd team, not to the package shipping a divert, because diverts are essentially invisible to normal users. It is already very difficult and very time consuming to support these packages, especially udev because we are essentially dealing with the intersection of an infinite combination of hardware and software, and anything that makes our lives harder is detrimental to the project at large. If there was a significant, or even any benefit at all, then it could be discussed, but I fail to see any. I do not find the theoretical point about multiple diversions very compelling - we use different mechanisms for different things all the time, but more importantly such a case simply has never surfaced in the 10 past years or so since we ship systemd by default, and longer since we ship udev. Moreover, as upstream developer, I can guarantee you that masking via diversion like this is NOT supported, and there could be more bugs lurking, and we categorically do not intend to support or help with such cases. I have no intention to spend any time investigating whether such bugs exist and document them. Therefore, given there is only one case in the whole distro so impact is minimal, the best option to me seems to flat out forbid it, so that we never get into that bad situation in the first place. Kind regards, Luca Boccassi
