Just my 2¢: On Sun, Jan 04, 2026 at 12:03:46AM -0500, Louis-Philippe Véronneau wrote: > 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 also run with exp tags visible here. > * update-debian-copyright > - last updated: 2022-12 > - 22,597 entries in UDD > - This tag was highly controversial when it was implemented and I don't see > its usefulness. I'd get it out of experimental, besides arguing about potential busywork, it's rarely "wrong" > * spelling-error-in-binary > - last updated: 2019-03 > - 336,571 entries in UDD > - As many pointed out, this tag frequently has false positives and even when > the issue is valid, it's often hard to fix them upstream. Nevertheless, it did catch plenty of real typos for me over the years. But it is indeed full of false positives, especially for short strings. Not sure if I'd be happy to see it just plainly drop tbh. > * systemd-service-file-missing-hardening-features > - last updated: 2018-12 > - 6,458 entries in UDD > - This check only looks if the systemd service file includes at least 1 > feature in a long list of "hardening" features. IMO, this is an overly > simplistic solution to a very hard problem. Yeah, agree with the drop. > * binary-file-built-without-LFS-support > - last updated: 2019-09 > - 25,628 entries in UDD > - To comply with this tag, the description mentions "[upstream] code review > might be needed". Considering the number of packages flagged and the > difficulty of the task, I feel this is outside of the scope of what a lintian > tag should recommend. ACK. Also, it's very 32-bit oriented and as such kind of going out of scope. > * exit-in-shared-library > - last updated: 2021-11 > - 33,020 entries in UDD > - The tag's description acknowledges that "In most cases, removing the call > should be discussed with upstream, particularly as it may produce an ABI > change". I feel this is outside of the scope of what a lintian tag should > recommend. What kind of "scope" do you see lintian as? It does also help improve quality outside of the plain debianization. Besides very few cases IME this is pretty much poor design, so I'd rather see somebody pushing more for these fixes. But I guess tuits are scarse as always. > * mentions-deprecated-usr-lib-perl5-directory > - last updated: 2018-08 > - The logic behind this tag seems dubious. The 9 entries in UDD all seem > like false-positives. I guess this was one case of Experimental:yes being used correctly ;) > * prefer-uscan-symlink > - last updated: 2021-11 > - 14,294 entries in UDD > - This tag asks individual users to change their ~/.devscripts configuration > file instead of using the filenamemangle option in debian/watch. I don't > understand how an individual change can be the solution to a collective > problem? I don't recall completely the origin, but I believe I was partly responsible for this: I'm of the strong opinion that `uscan` should default to provide a useful filename, instead of littering all d/watches with filenamemangle= rules. I still believe so. > * debian-watch-does-not-check-openpgp-signature > - last updated: 2018-12 > - 35,725 entries in UDD > - This tag was changed to Experimental because it was not really actionable > (#916207). I feel this is outside of the scope of what a lintian tag should > recommend. I still don't understand your "scope", but I agree it's not very useful. > * duplicate-files > - last updated: 2019-10 > - 117,663 entries in UDD > - This tag has been Experimental since 2011 and asks maintainers to do very > complex work (hunting and replacing "duplicate" files by symlinks) for very > little results. I feel this is outside of the scope of what a lintian tag > should recommend. Still unclear on the scope, but this is (…was, given cheap storage) useful work if done properly… > * dependency-on-python-version-marked-for-end-of-life > - 1 entry in UDD > - Python 2 has been removed from the archive a while ago and isn't coming > back. I have opened #1124516 to flag this issue for the only package that > raises this check. Yes, this has now done it job. > * application-in-library-section > - 9,847 entries in UDD > - The logic behind this check is flawed, as proven by the large number of > false-positives from the Python and Ruby sections. For certain languages, the > difference between "applications" and "libraries" is often arbitrary. The difference is arbitrary by definition. IIRC the login is simply: something in the "libary" section should not ship stuff in /usr/bin. How is that flawed? Besides, I've seen plenty of people bitten by this when the time came to do libary updates that required renaming the binary package, as you'd expect, when they did not do the proper package split just to save a NEW trip back then or something similar. In fact, to me it's very similar to development-package-ships-elf-binary-in-path that you argue should be kept, so… I disagree with removing this. > * library-package-name-for-application > - 7,769 entries in UDD > - The logic behind this check is flawed, as proven by the large number of > false-positives from the Python and Ruby sections. For certain languages, the > difference between "applications" and "libraries" is often arbitrary. This is normally part of the Policy for the packaging language. If the logic is flawed it should be fixed, but even looking at https://udd.debian.org/lintian-tag/library-package-name-for-application?affected=yes I don't really see any false positivies, just stuff that could have been done differently. I disagree with removing this. > * bin-sbin-mismatch > - last updated: 2020-08 > - 3,062 entries in UDD > - This tag checks to see if /usr/bin/foo is mentioned in a script which is > installed in /usr/sbin/foo. This logic seems somewhat dubious. It is also > apparently prone to false positives on ELF files. Why is it dubious to you? Loking at the list of false positives, to me this looks like a victim of the /usr-merge process that still needs to be fixed, so it can go back to display proper issues regarding sbin-bin instead of, for example, "bin/activemq -> usr/bin/activemq" (the first hit UDD shows). > * maybe-not-arch-all-binnmuable > - last updated: pre-2020 > - 1,215 entries in UDD > - This tag looks like it was a real "experiment" to verify something in the > archive. From discussing it on IRC, I think the experiment is now over. The experiment is however deciding it's too much PITA to do this right and for now too little gain. Plus I guess this is up to the people working on that effort. > === 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. No plese don't remove this. In fact, I reckon it should be brought out of exp. IIRC it triggers whenever you build stuff improperly and end up with a Distribution: in the .changes file different than what's in d/changelog, which can cause trouble (example: uploading to unstable instead of experimental). > * 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 wonder if this could be something handled in dh_fixperms in a new compat level, for example? The cases where this is required are all weird anyway. > * elf-warning > - last updated: 2021-11 > - 54,241 entries in UDD > - This tag uses the same valid logic as the elf-error tag, but for the > WARNING debug level. 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"? This is likely useful for statistics, if one wanted to. > * portable-executable-missing-security-features > - last updated: 2019-02 > - 499 entries in UDD > - This tag's description is horrendously confusing and includes a whole > section marked as "The following advice is historical. PLEASE DO NOT FOLLOW > IT." Not really sure if this is still relevant. No clue myself. > * non-consecutive-debian-revision > - last updated: 2021-01 > - 45 entries in UDD > - The logic in this tag is interesting, but it also applies to packages that > have already been released in the Debian archive (and as such, can't be > changed). It's weird enough (and trigger so seldom) that I'd take it out of experimental. > === Tags I think should be kept as Experimental === ACK all your proposals. > === Tags I think should be kept but not be Experimental === > > * upstream-metadata-file-is-missing > - 17,339 entries in UDD > - Although it is raised for a large number of packages, this tag is > pedantic, looks like a valid check and has a simple fix. I agree but only if the fix was less manual… janitor helped a ton here. ACK on the rest of the category. > === Tags that are explicitly "Experimental: no" (which is the default) === > > * systemd-service-file-shutdown-problems > * binaries-have-file-conflict maybe the result of flipping the "Experimental" switch off after testing? :) Thank you for picking up lintian! ♥ -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
