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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
