Re: two more tags
Russ Allbery wrote:
> Raphael Geissert writes:
>
>> Why false positives? I mean, I see no reason to ship files that only
>> make sense when developing under a Windows system even under
>> usr/share/doc; some files are even generated by Visual Studio which have
>> a big fat "DO NOT EDIT" warning which I'm not even sure if they can even
>> be distributed.
>
> In the abstract, I agree with you. (I'm fairly sure those files are fine
> to distribute, though; they're marked that way because they're
> automatically generated, but lots of free software projects that support
> Windows builds distribute them.) In the concrete, I'm concerned that it's
Well, my concern is because in the past I've seen some RC bugs filed against
packages because they were shipping files generated by a non-free program.
All of those files (except the .dsp, and .vcproj ones, IIRC) fall into that
category. I've no concrete opinion on this specific topic, though.
> too much of a nitpick. I know I bang this drum a lot, but Lintian becomes
> useless if people won't run it and pay attention to what it says, so I
> don't want to issue tags that people feel are just meaningless noise.
Sure, I agree.
>
> I'm not sure where this one falls. If you want to support Windows builds,
> those files *could* be useful as part of an example of how to do that.
> It's a bit of a stretch, but I can see it.
>
> There was a discussion in debian-devel some time back about how Debian
> maintainers should edit out the installation instructions in upstream
> README files since that information is useless in an installed Debian
> package. That's the sort of corner that I don't want to get us stuck in,
> since while all of that is of course perfectly correct, approximately no
> one actually does that, and it's work for no real gain for Debian. It's a
> lot easier, of course, to exclude a few files from being copied over, but
> if people are copying over whole example trees from upstream... I dunno,
> it may be fine to warn, but it does make me a little nervous.
>
I've been thinking for a while that the values in the checks/*.desc files
should be overridable (or whatever the right word is, as the spell checker
complains), i.e. in this case if the Windows devel file is not under
usr/share/docs emit a W tag, but if it is under usr/share/docs emit an I
tag instead (but of course using the same tag name).
I know this is very tricky because of the way lintian-info behaves, as the
other parts of the code can be modified to cope with the possibility of a
change.
There are many other cases where such a feature would be very useful,
experimental versions of some checks is an example.
A possible solution would be to add another entry in the .desc files for
each tag that can be overriden, e.g.
Tag: windows-devel-file-in-package
Overridable: type, severity
Type: warning
Severity: normal
Certainty: certain
Info: ...
$ lintian-info -t windows-devel-file-in-package
N: windows-devel-file-in-package
N:
N: This package appears to contain development files only meaningful to
N: Windows environments. Such files are generally useless in Debian
N: packages and were usually accidentally included by copying complete
N: directories from the source tarball.
N:
N: Type (default): warning; Severity (default): normal; Certainty: certain
N:
To make sure an explanation is given as to why the values may differ.
Of course Overridable could contain any of these: type, severity, certainty,
or experimental.
And adding such a feature before the next lintian release would be another
reason for the major version number bump. We could finally just add
extra 'lazier' checks for existing ones marking them as experimental
without worrying about introducing many FP's.
Opinions? ideas?
If there is no disagreement and nobody says out loud "I'll do it" I might
start implementing it this weekend.
Cheers,
--
Atomo64 - Raphael
Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Reply to: