Re: [PATCH] New Dpkg::Deps module to replace parsedep() and showdep()
On Mon, Oct 15, 2007 at 03:55:13PM +0200, Raphael Hertzog wrote:
> I'm running this code and up to now it seems to work fine. During the
> development, I also discovered a number of little bugs and oddities that I
> took the liberty to commit directly on the master branch.
> Please review and run it. I think it can be merged soon, just tell me to
> go ahead when you're confident. It would be nice to include it in the
> upcoming release as it automatically removes duplicate dependencies
> potentially introduced by dpkg-shlibdeps (and thus renders my wishlist bug
> #443973 useless).
A short review turned up no obious flaws. I have no objections against
merging it into master for inclusion in the next release.
- Should the parsing algorithm enforce the negated arch syntax, i.e.
that either none or all architectures need to be negated?
- Lack of attribution: I know the lintian code contains no
attributions, which doesn't neccessarily mean that this is a good
idea. You probably should add at least your name and the complete
attribution from lintian's debian/copyright since that should be
at least a superset of the correct one.
- for future patch sendings to the list I would prefer using a method
like on LKML, etc. I.e. sending each patch as a single mail. This
makes reviews piece-by-piece waay more pleasant. The git-send-email
tool can help with doing such mass-sendings.
> I think that adding some POD documentation to the module would help. Feel
> free to jump in. There's also two "die" functions that should probably by
> replaced some Dpkg::ErrorHandling functions. But as they are errors for
> programmers only (i.e. not the kind of error that an end-user will see), I
> left them as-is for the moment.
> (I have the feeling we already require translation of too many strings
> that users won't never see)
For consistency they probably should use a internerr none-the-less. And
generally I would rather err on the side of too much strings marked for
translation and let the translators decide whether they are worth
Frank Lichtenheld <email@example.com>