Re: Couple of patches
Raphael Geissert <atomo64+debian@gmail.com> writes:
> Russ Allbery wrote:
>> 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.
Thanks! The new version looks great. This should also let us fairly
easily implement #294927, #460174, and #471537 and it should help with
#478930 once the new copyright format is finalized.
> I remember seeing the other day some unneeded files being generated at
> unpack level 1 of binary packages.
More detail would be good. The only things that level 1 unpack of binary
packages generates are the control directory and index, the file indices,
and the breakdown of the package control information, plus a symlink.
It's worth remembering that almost no one runs Lintian with restricted
checks or with anything other than the default settings (thus unpacking
everything to level two). That doesn't mean we should completely ignore
those methods of running Lintian, but they shouldn't be a high priority
for development work, and I'm not sure trying to optimize that is a
particularly good use of time.
> 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.
If we were designing Lintian from the start, I'm not sure I see a point in
the unpack scripts and I think that sounds like a basically sound model.
Eliminating them is a lot of work, though. I guess I'm not feeling
particularly inspired to do the work. I could review it if you or someone
else does it, since in the long run having one fewer set of scripts will
probably save on some maintenance burden. But there's a lot of
backward-compatibility implications, and if you want my input on priority,
I think there are other things to work on that would be a lot more useful.
> Yeah, benchmarking/profiling is required.
Does anyone know of a good Perl profiling method? I did some cursory
searches for modules and didn't come up with anything that looked horribly
promising.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: