Re: Couple of patches
Russ Allbery wrote:
> Raphael Geissert writes:
>
>> Attached are two mboxs, one adds a some more words to Spelling.pm;
>
> Applied.
Thanks
>
>> 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.)
Didn't want to have our local copy, but fine; it just needs a four lines
function.
>
>> 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?
I remember seeing the other day some unneeded files being generated at
unpack level 1 of binary packages.
> (You
> can't tell from the declared dependencies, since the whole point of unpack
> level one is that everything can assume it's available.)
>
Well, I do know most of the code, and don't remember seeing some of the
files being used by all the collection or check scripts.
> 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.
I personally would prefer dropping unpack and doing all that stuff in
collection with a proper and simple dependency resolver (by simple I mean
keeping a low complexity level by not introducing things like Conflicts). I
see no reason to keep the unpack scripts as what all they do, IMO,
perfectly fit in the collection/ concept, and they both try to do the same
thing. An example of this is the file-info collection script, because what
it generates is an index of all the files with the file information.
>
> 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.
>
Yeah, benchmarking/profiling is required.
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
Reply to: