Re: CVS commit: pkgsrc

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

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

> On Mon, 2013-04-08 at 22:13 +0400, Aleksej Saushev wrote:
>> Adam Ciarciński <adam%NetBSD.org@localhost> writes:
>> 
>> >> Please, stop committing this nonsense immediatly!
>> >> And revert all the damage you have done so far.
>> >
>> > Why?
>> > It's a nice clean-up, isn't it? :)
>> 
>> No, it isn't a cleanup at all.
>
> You'll have to state exactly what you see as the problem.  Ideally
> without being rude.
>
> To an outsider, it looks like someone is taking the time to work on
> consistency across Pkgsrc.  It isn't clear why that's a bad thing.

What about stating exactly why this is a cleanup?

What I have seen so far in packages interesting to me:
 - build breakage (Squeak VM);
 - removal of search keywords and replacement of them with nonsensical
   abbreviations (libint);
 - violations of typographical styles that make package description
   unreadable (PostgreSQL packages).

If this is what pkglint recommends, then pkglint should be avoided.
At the very least, it shouldn't be trusted to be supreme source.

It isn't the first time I have to revert such changes. In previous time
it was calling "broken" the code that is widely used in Python packages.

In addition to that, pkglint tells absolute nonsense about variable 
substitution.
(Let us skip the issue that pkglint doesn't even handle variable substitution 
syntax.)

E.g. pkglint claims that "$$var" is "ambiguous" since "it isn't clear whether
it is shell variable or make variable" and then it recommends using "$${var}"
instead. It isn't hard to check that (a) bmake behaviour is consistent
and (b) we don't use another make. It may be that this warning was put
there out of good intentions, but the way it is done is broken.
First of all, the way the warning is reported doesn't make sense unless
you spend some time understanding that it means interpreting "$v" in make
and passing the rest to shell. Second, following the same logic make could
have interpreted "${var}" in make and pass "$<result>" to shell.
Third, given the preceding it doesn't make sense at all. If this ambiguity
situtation happens make should be considered broken and fixed accordingly.
Thus, the warning about "ambiguity" is nonsensical and should have been
removed.

The above "ambiguity" warning is rather frequent and thus it demonstrates
that pkglint ardent defenders do not analyze whether pkglint recommendations
make sense at all.


-- 
BECHA...
   CKOPO CE3OH...