Re: pkg/21932

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

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

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/21932
Date: Mon, 23 May 2022 02:45:09 +0000

 Seven years ago, I wrote:
  >  On Mon, Jul 27, 2015 at 07:15:00PM +0000, Erik E. Fair wrote:
  >   >  Please do not close this problem report - it is not resolved.
  >  
  >  Yes, that. Closing PRs just because they're old does not help anybody
  >  or anything...
 
 That said, this PR is now old enough to vote, and reviewing it, it's
 not entirely clear what the scope or intent is. The original report
 was about honoring a base-system make setting in pkgsrc, which (taken
 narrowly) is a bad idea, but for that purpose we have devel/cpuflags
 now and I think the original request is long satisfied.
 
 There's then some further discussion that seems to be about possible
 ways of tagging specially-built binary packages, including some
 infrastructure patches that are also now old enough to vote and almost
 certainly impossible to merge.
 
 My inclination would be to create a project page in the wiki about
 binary package variant tagging (if there isn't one already, I might
 have already written one years back), reference the material here
 there so it can be found again, then close this PR as the original
 request is handled.
 
 Note that tagging binary packages for variant compiler options is a
 special case and the problem really needs a general solution. (Other
 things that binary package tagging should handle include option
 settings, choice of compiler, native vs. pkgsrc X11, PREFER_PKGSRC
 settings, choice of security mitigations/theater...)
 
 Ideally it would be possible to have different variant builds of the
 same package in the same binary package repo so users can pick what
 they want. We've settled on a world where all this stuff is unlabelled
 and each package repo is expected to be self-consistent; it works
 adequately well but isn't as flexible as one might like.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost