On Sat, 27 Sep 2025 at 10:48:44 +0200, Samuel Thibault wrote:
Martin-Éric Racine, le sam. 27 sept. 2025 09:41:58 +0300, a ecrit:IMHO, in order for Lintian's severity levels to be meaningful in determining a package's fitness for inclusion in the Debian repository, an Error ought to refer to a MUST[NOT] Policy item,Tag: apache2-configuration-files-need-conf-suffix Severity: error Check: apache2 Explanation: The package is installing an Apache2 configuration but that file does not end with a '<code>.conf</code>' suffix. Starting with Apache2 2.4 all configuration files except module '<code>.load</code>' files need that suffix or are ignored otherwise. This is clearly an error that we want to highlight, while not actually being a problem for inclusion in debian, so won't be covered by the policy.
I think this is an excellent example, and I agree with Samuel that it would not make sense for Policy to forbid installing /etc/apache2/conf.d/foobar: the relevant more general meme is "Policy does not aim to forbid every broken situation".
It sort of is a problem for inclusion in Debian, because it's a bug of unknown severity: if you install /etc/apache2/conf.d/foobar into a package, expecting Apache to read it, then your package will not work as designed, which could be anywhere between Severity: grave and Severity: minor (depending on the package, and the importance of its Apache configuration being read). But not every bug is a Policy violation.
Similarly, I don't think it makes sense for every small-p policy to be part of Policy. We have things like a Python policy and a GObject-Introspection mini-policy, which not every DD needs to know about, only the ones who actually maintain relevant packages.
Historically, Lintian internally classified tags along two axes - impact and confidence - and then multiplied them to get the severity. For example, assessing /etc/apache2/conf.d/foobar as a mistake is high-confidence (I don't see any legitimate reason why a package maintainer would install a file to that directory unless they were expecting Apache to read it!), and that makes it a Lintian error, even though we cannot be sure that the resulting bug report from "Apache doesn't actually read this file" would be RC.
We also have Lintian tags for things like "Depends on a deprecated package that we are trying to phase out" or "relies on a deprecated behaviour that we are trying to phase out", as an alternative to mass-bug-filing. I hope you're not suggesting that we should be going through the intentionally formalized and heavyweight process of proposing Policy changes in order to say "Packages SHOULD NOT depend on python3-pdm-pep517" and "Packages SHOULD NOT depend on libgirepository1.0-dev", among others...
smcv