Peter Bonivart <[email protected]> writes: > On Wed, Dec 29, 2010 at 3:54 PM, Peter FELECAN <[email protected]> wrote: >> I'm not so fond of this kind of restrictions. Parser can be made >> "smarter" at small cost... > > The cost can grow when others find ways to demand "smarter" parsers. > What I found today was unexpected, what's it gonna be tomorrow? ;-)
The issue, as with many checkers is that their author tries to implement everything in a single parser, which has a tendency to have very complex ones. In my experience, is better to have a "herd of parsers" (TM) each one specialized on a quite simple domain. > What I suggested is a new check in checkpkg and all of those can be > overridden if needed. If a maintainer got such errors he could > probably in every case replace " - " with ", " and "::" with "-". In textual representation using the ASCII code the dash is used in place of the "long dash", e.g. in TeX represented with ---. Many times, this construct can be represented with parenthesis, semi-column or even comma. However, if somebody takes the description of a package as canonically represented in the upstream the thing get unnecessarily complex. > Here's the complete list: http://paste.pocoo.org/show/311358/ (don't > mind the "classification") Quite a mess but the description is a "free" content attribute of a package. Discussing the overrides, how are they functioning, as arguments of the checker or are they managed in the gar's Makefile? This shows that I'm not familiar with gar or checkpkg (Python version)... -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
