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

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

Joerg Sonnenberger <joerg%bec.de@localhost> writes:

> On Fri, May 15, 2020 at 10:38:13AM +0100, Jonathan Perkin wrote:
>> 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.

I think we actually don't see things that differently and are just
standing 90 degreees apart around the same elephant.  I will simplify
what I said, which is that there are multiple ways building packages is
done and we need to have a plan for which ways have which checks.
Situations are:

  A) random user does a build

  B) i) bulk build using defaults 
     ii) bulk build according to some standard recommendations

  C) people doing test builds prior to committing updates

  D) people patrolling for new kinds problems that are not yet in the
     category of being mostly fixed

I would argue that

  Bi should be equal to Bii.  Really, we should decide how bulk builds
  should be done (Bii) and set Bi to match

  A should be equal to B, unless there is a really good reason not yet
  articulated.

  There is no real need for anything optional about B.

  C should probably by default be as strict as it can be without causing
  lots of failures on things already on the tree

  D should be optional and can be as strict as people like
  
So my list collapses to "production build", "standard additional pre-commit
checks", and "new/experimental checks that if enabled, might cause
widespread fallout".

What you basically said, if I understood right, is that things in your
category 1 should be enabled for B.   And that things in 2 should be
added for C.   You didn't really address the experimental/D part.

It remains to:

  sort checks into "always", "pre-commit", and "experimental"

  decide on variables


I think we should keep PKG_DEVELOPER to mean my category C.

And we should keep CHECK_PORTABILITY_EXPERIMENTAL, perhaps enabling all
CHECK_FOO_EXPERIMENTAL if PKG_DEVELOPER_EXPERIMENTAL is set.

Which leads to "move any check that should be run in category B to just
run".

> I'd draw the line somewhat different. I'm pretty much fine with most
> checks from PKG_DEVELOPER to become default if
> (1) They are reasonable fast (relative to the time pkg_create takes).
> (2) They don't require additional software.

That's a very good point and I mostly concur.  I think most of what
Jonathan wants to move to "always" is as you describe.  And implicit in
your comments: obviously we can't depend on pkglint.

I do not find really minimal packages, that depend on sh and C only, to
be a real problem here.  We already require things like digest and as
long as they are like that, it doesn't upset me.


So I'd say we have mostly consensus, and people can change individual
checks that meet Joerg's "reasonably fast" and "no extra tools" from
only running if PKG_DEVELOPER=yes to always running.

Once we have those moved, PKG_DEVELOPER=yes can be removed from bulk
builds.

Things that require any additional packages, even if tiny, I think still
merit discussion.