Hi! On Sun, 2026-01-04 at 00:03:46 -0500, Louis-Philippe Véronneau wrote: > In an act of productive procrastination, I spent a few hours > yesterday looking at the tags in Lintian that are currently marked > as "Experimental: yes". > > As far as I understand, very few people run Lintian at the experimental > level, which means these tags are still ran, but not really shown to > users (and thus waste CPU cycles).
(I do! :D, this is my config: ,--- ~/.config/lintian/lintianrc: #show-overrides=yes tag-display-limit=0 display-experimental=yes display-info=yes pedantic=yes color=auto `--- ) > I'm emailing the Lintian and QA lists in order to get some feedback > before creating a big MR with tens of commits removing the tags I > feel should be removed. If you think the reasoning below is flawed, > please reply to this message and let me know! I think several of the tags that you are planning or considering for removal are useful. But perhaps not in their current form. The problem as you note is that several of those flag things that the maintainer might be unable to fix by themselves, which can be seen as frustrating. I still think these are useful, because they flag things that are for example otherwise best-practice, or that are smells. Not flagging them makes these problems invisible, although they are still there. So perhaps the problem is mainly that they should be closer to the "classification" tags, but specific to these kinds of issues, say "smell", "best-practice", "aspirational" or something similar, and not emitted by default unless requested somehow. Also AFAIK, some QA tools depend on flags being emitted to track issues or report stuff. > === Tags I'm planning to remove === > > * update-debian-copyright I think it's a good reminder, if you want to update your copyright statements. (<smell/aspirational>?) > * spelling-error-in-binary While it indeed has false-positives, I've found it still triggers on valid issues, that I've reported upstream with patches, so I appreciate its existence. (<smell/aspirational>?) > * systemd-service-file-missing-hardening-features I think this might be fine as an aspirational one, but otherwise depending on the daemon, and depending on what hardening gets applied for a general purpose distribution, might easily break stuff, for example for non-default options. (<smell/aspirational>?) > * binary-file-built-without-LFS-support Removing the tag will not remove the problems (as long as we support 32-bit arches). I think having this gives the problem visibility. > * exit-in-shared-library While this one I've found hard to fix, I still appreciate its existence to be aware of these problems. (<smell/aspirational>?) > * prefer-uscan-symlink This one has always seemed very strange to me, and I meticulously ignore it. I think if anything should be fixed that should be in uscan perhaps. > * debian-watch-does-not-check-openpgp-signature This is an easy ask, even though upstream might as easily reject it, because they might not be prepared or willing to do OpenPGP stuff. I still find it useful, to track which ones are missing upstream signatures. (<smell/aspirational>?) > * duplicate-files I think this is useful, and worth reporting upstream at least. (<smell/aspirational>?) > * application-in-library-section > * library-package-name-for-application I actually think most of the problems flagged by this are valid. With packages incorrectly marked as libs, or programs shipped in shared library packages, or in python or perl module packages, or non-development programs marked with their implementation language which should be irrelevant. But given that for interpreted languages we do not have the libs vs libdevel vs devel distinction, the language section gets all these into it. :/ Perhaps a compromise for now could be to ignore language specific sections for now? (Although as mentioned above, I think several of those are actual problems IMO.) > * bin-sbin-mismatch Unless the test can be improved this seems like a rather experimental and error prone one to me. (AFAIR I filed a report about this one.) > === Tags I think should be removed, but could probably stay Experimental? === > > * bad-intended-distribution > - last updated: 2014-11 > - 15 entries in UDD > - I don't really understand this tag? It seems to me like the > unreleased-changelog-distribution tag already takes care these > kind of issues. The entries in UDD mostly look like false-positives. This tag is supposed to match what the uploader intended when spelling the target distribution in textual form in a changelog entry, against the entry in the changelog entry header. But it's true that it seems prone to false positives. The unreleased-changelog-distribution checks (AFAICT) whether a signed .changes is not for the boilerplate 'UNRELEASED', which seems more reliable, but does not catch mismatches in intention. I guess this might be one of those that might be effective during the preparation when you notice the mismatch before uploading it, and then fix it? > * executable-in-usr-lib > - last updated: 2022-01 > - 159,250 entries in UDD > - The logic behind this tag is valid. Considering the very large > number of entries in UDD, I don't think this will be fixed. What > is the point of having a tag if we're not willing to show it for > fear of "wasting people's time"? I think this flags a valid issue, and even if fixing it might be hard or not happen in a quick way, it serves as a way to provide awareness and to track progress over time. (<smell/aspirational>?) > * elf-warning > * portable-executable-missing-security-features I also think these are useful, even if not going to get down to 0, for the same reason as the others. (<smell/aspirational>?) > * non-consecutive-debian-revision Seems also useful, but in many cases not worth fixing. (<smell/aspirational>?) Thanks, Guillem
