On Tue, 6 Jun 2023 14:03:41 +0200 Bill Allombert <ballombe@debian.org> wrote: > On Tue, Jun 06, 2023 at 12:16:39PM +0100, Luca Boccassi wrote: > > > > local administrators and local packages to override the behaviour of > > > > Debian. Its use between Debian packages should be rare, should involve > > > > coordination between the packages and their maintainers, and must only > > > > be used to solve problems that cannot be handled through other > > > > facilities or native mechanisms. In other words, packages in Debian > > > > must not divert a file from another package unless this is arranged > > > > cooperatively between the packages to solve some specific and unusual > > > > problem. > > > > > > How about: > > > > > > Diversions and alternatives are primarily tools for local > > > administrators and local packages to override Debian's default > > > behaviour. Maintainers should prefer to use other, package- specific > > > facilities for overriding configuration, such as systemd's unit file > > > overrides, wherever possible. > > > > > > If diversions and alternatives are to be used, maintainers should > > > co-ordinate with the maintainers of all the packages involved. For > > > example, configuration files used by systemd components should not > > > be diverted with dpkg-divert or the alternatives system without > > > agreement between not only the maintainers of the packages that ship > > > the files, but also the maintainers of the relevant systemd > > > components. > > > > As above, as long as this wording makes any offending package > > rc-buggy, it's fine by me, but my understanding is that using 'should' > > doesn't guarantee that. Please correct me if I'm wrong here. > > I do not think there is consensus that this should be a RC bug outside of > a case by case basis. It is already awkward to mention systemd explicitly > in this paragraph. > > The diversion system is made precisely to work around other packages behavior, > this is a feature not a bug. That it should only be used as last resort, I > think everyone agree. But when it is, it should not be a RC bug. This is a technical matter, I'm not sure what 'consensus' means in this context? Things _will not work_ as expected by shoe-horning dpkg's overrides onto systemd mechanisms, they _will_ break in weird and unexpected ways, and we as maintainers _will not support it_ - whether somebody else agrees or disagrees with this won't change any of it. It means that, when such bug happens, and it turns out there's a divert/override in the way, the bug will be an immediate close+wontfix and the reporter will be told they are on their own. And that's a best case scenario where it is all apparent, while actually it's more likely this will be hidden away and require a large waste of time to figure out. Isn't it better to ensure this cannot happen in the first place? Once more: there are no such cases as of bookworm in the archive, so the impact today is nil. Wouldn't it be prudent to ensure it stays that way in the strictest possible terms? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part