On 1/4/26 5:54 AM, Niels Thykier wrote:
Holger Levsen:
On Sun, Jan 04, 2026 at 12:03:46AM -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".
yay & thank you for that!
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).
this does not compute however, or is it really the case that lintian
checks
for experiemental issues *always* while only showing them if asked? If
so,
I'd think the obvious fix would be to only run them if asked to?
(I care because I do run lintian on experimental level always
(pedantic too)
and thus I also very much appreciate your cleanup!)
[...]
Based on how it worked when I last worked on Lintian (~7 years ago), the
logic is this:
* A "Check" had 1 or more tags. If at least one tag from the "Check"
was active, then the "Check" was active and would be run. This was on
a profile level or options like `-X`. Display filtering (such as
`-EvIL +pedantic`) were not considered at this point.
* Once a "Check" runs, it would test for all the tags it provide. Any
kind of "this tag is disabled" or "this tag will not be shown due
visibility options or overrides" was handled at a central level.
This kept the checking code a lot simpler as it only had to consider the
logic about the tags and not visibility or enabled/disabled. For those
not in the know, this was also part of why changing visibility of tags
were not an absolute pain since you literally only had to change the
visibility (and then any tests that depended on the visibility).
Most tags were relatively fast to compute individually (with the non-
free license regex-based tags being a notable exception). The "heavy"
bit tended to be "unpack + collection" phase (extract + run `file` + run
`readelf`/`objdump` + run `strings`).
The main win would have been to disable all "Check"s needing a
particular (data) collection. But that never happened in practice (you
just needed one important tag to need `readelf` and then due to the
dependencies you would have to full heavy unpack chain).
Additionally, in my time, there were ~20 "Check"s with a high average
number of tags spread across all visibility levels. In practice, you
would never disable a "Check" due to visibility. My understanding is
that Lintian now has 100+ "Check"s meaning the average number of tags
per "Check" would be a lot smaller. With that in mind, using visibility
to disable irrelevant "Check"s might now be somewhat useful.
As said, this information is ~7 years old and accordingly the use of
past-tense.
Thanks for the summary, that's also my understanding of how Lintian
currently works.
Even though it would "make sense" to not compute all the tags all the
time, I have no plans on changing this behavior, as it would require a
very important refactor. I have neither the energy nor the Perl (maybe
even the general programming) skills to do so.
If someone else wants to tackle this task though, Lintian is always in
need of help! I'm the most active maintainer at the moment, but I'm
mostly reviewing and merging other people's code, as I lack the time to
do more.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ [email protected] / veronneau.org
⠈⠳⣄
