Re: On the quest for automated QA checks
Rogério Brito <rbrito@ime.usp.br> writes:
> I'd like to make it clear that I'm just brainstorming here and that at
> this stage, I'm not really concerned with the feasibility of the ideas.
> I'm just doing a "what if" thing.
Oh, sure, totally understood.
> On May 02 2009, Russ Allbery wrote:
>> Lintian should catch this already, although we may not have the most
>> recent ones. If you know which are missing, please file a wishlist
>> lintian bug.
> dh_movefiles doesn't seem to be catched, from tests of today. I don't
> know if lintian is really the proper place to put those tests, but it
> wouldn't hurt, even though I think that debhelper should generate such
> things.
Ah, yes, that isn't deprecated, strictly speaking, but yeah, we should
probably say something about that. Please do file a bug for that!
I think Lintian's a good place to put such warnings. We already do so
for several other deprecated debhelper programs.
>> This is hard to analyze properly. The package should not be relying
>> on environment variables set by dpkg-buildpackage, since then
>> debian/rules build doesn't work.
> Hummm, I'm not sure that I get it, but it seems to me that
> dpkg-buildpackage already does that, doesn't it? It seems to pass
> flags like -O2 -Wall, if I'm not mistaken... Please *do* correct me if
> I am wrong.
dpkg-buildpackage does, but I wish it didn't because people then assume
that debian/rules can always rely on those variables being set. It
can't, because building the package by calling debian/rules build
directly is also valid, and is a pretty common thing to do for debugging
and while working on problems. Or at least it can't right now; there's
some discussion of changing that (and I owe Raphael a reply about that).
>> > * seeing if a given package providing a library has the -dev package
>> > containing the soname in the name of the package (e.g., libfoo0-dev).
>> This is sometimes the right thing to do, sometimes not.
> I know, I know. Just putting a very low priority thing to lintian
> could be done...
This one's hard -- it's part of a set of tags that one really wants to
present once for the initial packaging in sort of an "are you really
sure" way but then not show again. This is the place where I think
something on mentors may make a ton of sense, or some way of putting a
mode into Lintian for "check my non-uploaded package."
> Let me restate here that I'm just brainstorming. Perhaps lintian could
> have a category of tests labelled "expensive" tests, where the person
> running lintian would be willing to run also a compilation thing in a
> chroot/virtual machine/whatever environment.
I wonder if the easy way to do this would be to write something (this
wouldn't be Lintian) that analyzes a build log for interesting issues.
>>> * seeing if the long description passes a spell checker test (running
>>> ispell or whatever).
>> Lots and lots of false positives for this. I don't think it's worth it.
> This could be in the "expensive" category of tests, I think.
Yeah, but this one I think you'll find is, in practice, pretty much
unusable except maybe as a hint to someone who's willing to scan through
all of the product names, people's names, partial URLs, command names,
and so forth. Package descriptions are really horrible cases for
conventional spell checking.
> Oh, perhaps, doing a licensecheck call could be a good thing, if only
> to let the maintainer know what is happening and that Debian *does*
> care about this.
Yes. I think running licensecheck for mentors uploads would be great.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: