Re: pkglint is broken and harmful

[Aleksej Saushev <asau%inbox.ru@localhost>]

David Sainty <dave%dtsp.co.nz@localhost> writes:

> On Wed, 2013-04-10 at 23:09 +0400, Aleksej Saushev wrote:
>> 
>> 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...

The main problem is that pkglint is taken as sort of authority
where it isn't actually. You can easily look around and see how changes
are made just to silence pkglint warning without any thinking what
the warning is about and whether it is correct at all.

In other words, with much worse quality by design pkglint is treated as
higher authority than lint in the base system.

>> 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.

There's abundancy of Perl, Python, and Ruby packages using "unusual"
file names. Soon there will be more packages of similar kind, and
I doubt very much that pkglint will grow support soon enough.

>> 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.

I'm more realistic than you think, I don't require introduction of
typesetting features into pkgsrc framework. What I do want is to see
at least some understanding that pkglint warnings affect how these texts
are presented to end user. Our tools suck very much already and there's
absolutely no need to make it worse.


-- 
BECHA...
   CKOPO CE3OH...