Re: pkg/46570: infelicities in pkglint

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/46570; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 9 Jul 2012 20:32:25 +0000

 On Mon, Jul 09, 2012 at 05:45:02PM +0000, Thomas Klausner wrote:
  >  I'll not comment further about the complaints about the language,
  >  because it is a well-written script in a language intended for
  >  handling text, and does it job well for single packages.
 
 As long as there's someone maintaining it, I don't care what language
 it's written in. Heck, translate it to befunge or INTERCAL for all I
 care.
 
 However, if (as has been the case for some time before today)
 maintenance is left up to passersby and passersby are not able to
 successfully modify the thing, it constitutes a problem.
 
  >  > - It does not understand USE_GAMESGROUP or its accompanying
  >  > paraphernalia, and issues a bucket of spurious warnings instead of
  >  > guiding correct usage. I looked into fixing this at one point and was
  >  > stopped by the first two issues.
  >  
  >  I've just fixed these issues. USE_GAMESGROUP wasn't even documented in
  >  the guide, so I fixed that as welll.
  >  
  >  > - It has a system of permissions for make variable usage in various
  >  > contexts, which is fine, but when it warns about violations it reports
  >  > the permissions as single letters. The letters are not documented in
  >  > the man page. To find out what they mean, you need to UTSL (see points
  >  > 1 and 2) or notice the -e option. It should use words in the
  >  > diagnostics, especially since we encourage novice packagers to use
  >  > pkglint.
  >  
  >  I've added a reference to -e in the final output line if any problems
  >  were found, and documented the permissions in the man page.
 
 That's a start. How about having it output words? Then it wouldn't be
 necessary to look them up or explain them.
 
  >  > - It will happily attempt to check gmake makefiles (which can appear
  >  > in a package's files/ directly) ... and then when it encounters gmake
  >  > syntax, which it doesn't understand, it doesn't even spew errors but
  >  > *aborts*.
  >  
  >  I don't see how this is a problem, since this is intended for checking
  >  pkgsrc Makefiles and only to be called from pkgsrc/category/program,
  >  where no GNU makefile should ever reside.
 
 They can and do reside in files/, and when invoked with -Call as is
 usually recommended, pkglint takes it upon itself to inspect the
 contents of files/ and becomes confused. For example:
 
 % cd archivers/libarchive/
 % pkglint -Call
 FATAL: files/Makefile.am:175: Unknown line format: ./files/Makefile.am:175: if 
INC_WINDOWS_FILES
 Exit 1
 
  >  > - If it encounters a file called Makefile.PL it expects it to be a
  >  > makefile (rather than a perl script) and *aborts* when it finds the
  >  > syntax confusing.
  >  
  >  I don't see how this is a problem, since this is intended for checking
  >  pkgsrc Makefiles and only to be called from pkgsrc/category/program,
  >  where no Perl Makefile.PL should ever reside.
 
 They can and do reside in files/, and when invoked with -Call as is
 usually recommended, pkglint takes it upon itself to inspect the
 contents of files/ and becomes confused. For example:
 
 valkyrie% cd sysutils/p5-UPS-Nut/
 valkyrie% pkglint -Call
 WARN: ../../sysutils/ups-nut/Makefile.common:7: Please add a line "# used by 
sysutils/p5-UPS-Nut/Makefile" here.
 FATAL: files/Makefile.PL:4: Unknown line format: ./files/Makefile.PL:4: 
WriteMakefile(
 Exit 1
 
  >  > - It doesn't understand the .-include "file" syntax and *aborts* upon
  >  > encountering it in a makefile.
  >  
  >  I don't see how this is a problem, since this is intended for checking
  >  pkgsrc Makefiles and only to be called from pkgsrc/category/program,
  >  where I didn't find any occurrence of ".-include" in the current
  >  pkgsrc tree, nor do I expect any to appear.
 
 You didn't look in files/. Makefiles with this construction can and do
 reside in files/, and when invoked with -Call as is usually
 recommended, pkglint takes it upon itself to inspect the contents of
 files/ and becomes confused. For example:
 
 valkyrie% cd devel/bmake/
 valkyrie% pkglint -Call
 FATAL: files/Makefile.in:101: Unknown line format: ./files/Makefile.in:101: 
.-include <bsd.prog.mk>
 Exit 1
 
  >  > - Currently when run in ruby18-base it somehow imagines that it should
  >  > be looking at ruby19-base's patches and spews about six screenfuls of
  >  > completely nonsensical errors.
  >  
  >  I can't reproduce this on ruby18-base nor ruby19-base, so I suspect
  >  this has been fixed in the meantime.
 
 Yes, this has apparently been fixed. It was polluting the weekly check
 runs and therefore moderately visible.
 
  >  > - It complains incorrectly about not being in -e mode if it encounters
  >  > a makefile recipe with a shell for loop, because of the semicolon in
  >  > the for loop syntax.
  >  
  >  Can you please give me an example package where I can reproduce this?
 
 Not offhand, because I have been changing them when I find them.
 However, you don't need an existing example; just take your favorite
 test package and add this:
 
 post-install:
        for x in foo bar baz; do \
                ${INSTALL_PROGRAM} "$$x" ${DESTDIR}${PREFIX}/share; \
        done
 
 then run pkglint -Wall. You will get:
 
 WARN: Makefile:37--39: Please switch to "set -e" mode before using a semicolon 
to separate commands.
 
 On reflection the warning may be coming from the ; before "done"
 rather than the one before "do", but the shell won't accept && there
 so it's still wrong.
 
 
 And, btw, another one: pkglint bails out if it encounters a makefile
 line of the form "foo : bar", with a space before the colon. Arguably
 it's correct to object to this, but it shouldn't crash.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost