Re: Defaults for PKG_DEVELOPER=yes

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

David Brownlee <abs%absd.org@localhost> writes:

> OK, so it looks like PKG_DEVELOPER affects the following checks:
> - CHECK_INTERPRETER
> - CHECK_FAKEHOME
> - CHECK_HEADERS
> - CHECK_PERMS
> - CHECK_PIE
> - CHECK_PORTABILITY
> - CHECK_RELRO
> - CHECK_SHLIBS
> - CHECK_SSP
> - CHECK_STRIPPED
> - CHECK_WRKREF
>
> Also sets:
> - MASTER_SORT_RANDOM=NO
>
> Plus adds some extra verbosity:
> - mk/pkgformat/pkg/metadata.mk
> - mk/tools/pkg-config.mk
> - mk/license.mk
> - USE_CMAKE (warning if PKG_DEVELOPER set)
> - FONTS_VERBOSE
> - A scattering of package Makefiles
>
> So I think PKG_DEVELOPER for the non CHECK_* values still makes sense.

More or less, PKG_DEVELOPER seems to mean "I am somehow who fixes little
things, so tell me about them, as opposed to a user trying to build
packages."   I think that is likely to continue to make sense as a
concept.

Because package developers generally have PKG_DEVELOPER set, I suspect
most packages have most things that cause packages to fail fixed or
worked around.

Howver, any particular thing should be evaluated on its own merit,
asking what's appropriate for someone just building, vs someone who is
poised to fix.  There are basically three outcomes for a problem:
quiet/warn/fail.

So, for many CHECK_FOO, if we consider that they are important, in that
the package is broken without them, we should perhaps just default them
on, rather than defaulting them on only if PKG_DEVELOPER is on.

This I think leads to a need to allow CHECK_FOO=no in mk.conf, which I
hope already exists for each FOO, but perhaps not entirely.

> I'd like to introduce a new variable - PKGSRC_SKIP_CHECKS? and replace
> PKG_DEVELOPER usage in the CHECK_* case with it (inverted)

I don't think this makes sense.  I think we want people to be able to
turn off any particular check if needed, but that as long as we don't
expect them to fire, there's no real reason to omit them for user builds.

> Any objections to the plan (or naming)?
>
> This might be ready for the Q4 branch, but will not commit to the tree
> before that branch without confirmation :)

That seemed out of the question to me even before I read the next
message :-) Plus, there's nothing urgent about this.

My impression is that most bulk builds are setting PKG_DEVELOPER=yes.
If not, it would be interesting to see how much trouble that causes, and
also for a change to default on man of the checks.


As for specific, FAKEHOME should probably be warn, vs fail.   I bet
there's a lot that is trouble.

As for extra verbosity, I would be inclined to see if this could/should
be reduced.   Deprecation warnings might be reasonable to keep.


In summary, I see this as a bunch of little questions, rather than a
large-scale bump.