Re: Couple of patches
Raphael Geissert <atomo64+debian@gmail.com> writes:
> Attached are two mboxs, one adds a some more words to Spelling.pm;
Applied.
> the other mbox contains the necessary changes to generate an index of
> the source package, and file-index.
Need to be rewritten to not use Dpkg::Version, which is not available in
stable. It looks good once that's done. (If past experience is a guide,
it will take some time before gluck is updated to lenny even once lenny is
released.)
> The other day I was thinking that it should probably be better if the
> indexes and some other info being generated by the unpack scripts are
> moved to collection, and a simple dependency resolver applied to the
> collection scripts. This would not just in theory speed up lintian when
> not all the checks are run, not to mention the cleanup of the unpack
> scripts.
> What do the others think about it?
I don't understand the benefit, I guess. Why would that speed anything
up? Are there really any checks that don't use unpack level one? (You
can't tell from the declared dependencies, since the whole point of unpack
level one is that everything can assume it's available.)
Also, I don't think it makes sense to do that without completely redoing
the architecture of data collection. Generating those indexes *is*
unpacking to level one. If that moves to collections, there's really no
point in having the whole concept of unpacking. I'm not sure I see a
benefit that would warrant that degree of change, and I'm not sure why it
would be a cleanup.
But I might just be missing something and would be all in favor if I
understood more.
> We should also think about how to be friendly to the kernel's file
> caching, to speed lintian up. Because the more checks are added, the
> more info is collected, the more it slows down.
I suspect that the writes of unpacking and the forks of all the file
commands are killing us more than reads, but I haven't benchmarked it.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: