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

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%joyent.com@localhost> writes:

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

Already responded to some, but:

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

Agreed.

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

So this is

  checks that are PKG_DEVELOPER=yes now, that don't get promoted to
  always, plus

  new checks that might cause half of existing packages to break

> FWIW I have always run my bulk builds with PKG_DEVELOPER=yes set (for
> the above reasons),

Yes, and the official TNF ones do this too.

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

Interesting, and I think it's fine for anyone doing a bulk build to add
that sort of thing.

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

These presumably are done just to look for trouble, not to publish.

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

So far, I have not heard anyone argue against promoting these basic
checks, not involving extra code, to always be in effect.



I don't really want to have new checks that are likely to cause lots of
failures be put in PKG_DEVELOPER.  I build packages in three ways:

  When testing an update.  There I'm generally happy to have full-on
  checks.

  Just building something because I want to use it.  I don't mind what
  we have in PKG_DEVELOPER now.

  Doing pkg_rr, which is more or less like a bulk build.  I don't mind
  the checks that were on last time being on (today's PKG_DEVELOPER).
  I very much do not want new checks, unless people believe that 95% of
  the current tree is ok with them.