[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
Some notes:
 - 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
translating.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/



Reply to: