Re: PKG_DEVELOPER=yes [Re: CVS commit: pkgsrc/lang/zig]

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2020-05-15 at 02:19 BST, Greg Troxel wrote:

> Perhaps we should think in terms of multiple levels of checks, rather
> than PKG_DEVELOPER=yes or not.  As I see it there are multiple
> situations:
> 
>   1) random users building packages
>   2) users who are testing package changes for gnats or wip
>   3) people with commit access to pkgsrc who are building/testing,
>      perhaps prior to commit
>   4) people who are looking for trouble
>   5) bulk builds

I don't really see it that way.  I see two clear distinctions:

 1. Checks that ensure that a package is built correctly.

 2. Checks that try to improve the quality of the package metadata.

The problem we have right now is that some of the basic "does this
package even build correctly" checks are hidden behind PKG_DEVELOPER,
when they clearly should be always on.  There is absolutely no merit
in being able to build a broken package, much less allow someone to
commit something that absolutely can't work when installed.

I think it should be pretty easy to come up with a list of checks that
should be moved out from under PKG_DEVELOPER.  Joerg already made a
good start here.

The second class, and what I'd change PKG_DEVELOPER=yes to mean, would
be all of the static checks that try to fix issues in the package that
do not affect its installation.  Stuff like Roland's SUBST cleanups,
running pkglint, extra CHECK_PORTABILITY tests, fakehome stuff, etc.

These are all nice to have, and should always be enabled and fixed by
developers before commit, but don't in general affect the quality of
the installed package.  For example, it's pretty clear that an
indentation alignment issue in a Makefile shouldn't stop a regular
pkgsrc user from building a package.

> It's not really clear how 5 should be set; I don't see any real argument
> for 1 being less strict than 5. and I don't see why 4 should be stricter
> than 1.

FWIW I have always run my bulk builds with PKG_DEVELOPER=yes set (for
the above reasons), and in many cases enable extra checks.

For example, by default I enable "CHECK_WRKREF=tools home", and then
for my release builds I have additional CHECK_WRKREF_EXTRA_DIRS set to
try and catch any lingering references to additional tools locations
that I use for builds.

I also set CHECK_SHLIBS_BLACKLIST to ensure that PREFER_PKGSRC is
being used correctly and that we aren't accidentally picking up
library references to those shipped with the OS.

And for some bulk builds I also shake up the layout a bit, so that
assumptions like PKG_SYSCONFDIR being under LOCALBASE, or specific
PKGMANDIR directories (and MANZ settings) are challenged.

My opinion is that shipping broken binary packages to users is one of
the absolute worst things we can do.  In many cases this is someone's
first interaction with pkgsrc, and its our chance to show them that we
know what we're doing.

If they try to install something and it's completely busted with
missing files, references to random directories from the build host,
broken paths, hard to diagnose crashes because the wrong library is
being pulled in somewhere or whatever, then they move somewhere else
with a very negative first impression of us, which we can never go
back and fix.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com