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