Re: pkglint is broken and harmful

[David Sainty <dave%dtsp.co.nz@localhost>]

On Wed, 2013-04-10 at 23:09 +0400, Aleksej Saushev wrote:
> Hello,
> 
> Since these problems recur each time some new developer joins the project,
> I have to reiterate it.
> 
> pkglint in its current state is broken and harmful.

It helps maintain a level of consistency, and check for common mistakes.
In return for that, a little bit of forgiveness for its imperfections
isn't out of place...

Its suggested changes can usually be followed with no actual pain
incurred.

> pkglint operates by matching _some_ (not all) files against a set of
> regular expressions and using some sort of heuristic, almost undocumented,
> to warn about potential problems. This alone is a strong reason
> to be critical of warnings rather than act so as to silence them.
> Matching regular expressions is too limited in power to be
> an authorative guidance.

That's typical of lint-style tools in general.  To do the job of
linting, it's typically necessary to work _above_ the target language,
in order to see non-functional flaws.

Using an unusual filename in Pkgsrc could be seen as a non-functional
flaw.  You could break a standard package Makefile into 30 files and
include them all together.  make(1) would handle it - but you'd want
pkglint to get annoyed about it.

> pkglint doesn't handle semantics of make language. At all.
> This leads to "fixes" where correct code like
>   $(MKDIR) $(CONFIGURE_DIRS)
> is replaced with incorrect one like
>   $(MKDIR) $(WRKSRC)/$(CONFIGURE_DIRS)
> Human reader notices immediatly that this violates typing considerations:
> you're trying to treat a list of strings as a simple string while make
> doesn't implement it as implicit "map". This is how working around
> a problem in pkglint to silence warning leads to conceptually broken code.
> 
> To add to the latter, pkglint embeds knowledge that CONFIGURE_DIRS is a list,
> but it doesn't perform any checks that such variables entry operations
> allowed by type.
> 

Sounds like an opportunity for pkglint to improve :)


> The last, but not the least, pkglint seems to be written by people who
> have never tried to learn basics of typography. This alone is not bad
> except that in this case reasonable person should not pretend to be an
> expert and suggest stupid formatting rules that affect how text is typeset
> and presented to end user.
> 
> In particular, pkgsrc/biology/mpqc/DESCR ends as
> 
> http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/biology/mpqc/DESCR
> 
> which is reachable and supposed to be reachable from the web site.
> What is more important, it is supposed to be read by end user in his
> web browser. Thus it should be typeset reasonably enough for a web user.
> 
> 80 characters per line requirement pkglint insists upon has no basis
> nor support among typographic designers and other specialists in
> cognitive sciences.
>
> Classic recommendations are 45-60 characters per line here, and these
> are based on field observations (e.g. classic data from newspaper sales)
> and experiments. (Though there exist modern data that favour _longer_ lines
> under some conditions, but those around 90-95 characters per line,
> still different from 80.)

pkglint won't complain about a 45-60 width DESCR I don't think?

> In addition to that, there exist strong indications that structured text
> is perceived better than less structured one. It has better readability,
> where "readability" is a typographical _term_ rather than some handwaving
> about the number of columns in IBM PC text mode. (The latter matches
> the number of columns on punch card which was made to be equal to
> classical number of characters per line plus allowance to accomodate
> unusually long lines plus space needed to carry punch card position
> in a deck.)

80 columns has a lot of momentum behind it, both in terms of display
size and existing DESCR files.  It's the obvious greatest common
denominator, which is why (almost) everyone is happy with it. You can
argue and even demonstrate that it should be different, but that ship
has pretty much sailed.

At any rate, it sounds to me like you don't want DESCR at all, you want
something marked-up.  And DESCR clearly isn't that thing.