[Bug 262639] Add support for make.conf helper variable to disable FLAVOR

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 18 Mar 2022 01:47:07 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262639

            Bug ID: 262639
           Summary: Add support for make.conf helper variable to disable
                    FLAVOR
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Ports Framework
          Assignee: portmgr@FreeBSD.org
          Reporter: bofh@freebsd.org
                CC: ports-bugs@FreeBSD.org

Created attachment 232540
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232540&action=edit
Disable flavor in PHP

Currently our php.mk is defined in such a way that when testing with poudriere
if a port do not support the PHP default version it tries to build with a
different php version that the port supports. Unfortunately this behavior is
not too much helpful when we want to add/remove a old/new php version as it
doesn't gives a clear picture of which ports fails to build with a specific PHP
version. So this patch defines a variable "BUILD_ONLY_DEFAULT_FLAVOR". If this
variable is defined in make.conf then poudriere will build with default flavor
and in case it's not supported this will IGNORE/SKIP the port which gives a
clear overview of which ports are going to create problem while
adding/removing/changing default php. For example if you go here you can see
how the ports are ignored/skipped while this variable is setup:
http://pdr.bofh.network/build.html?mastername=130-default-PHP80&build=2022-03-09_03h23m04s

One major issue is not all port maintainers use PKGNAMEPREFIX while flavoring
their ports which actually creates the problem. Hence some ports ignores while
the others tries to build them using the supported php version even though it
is not the DEFAULT php.

One more thing is there are some old php modules still listed specifically
dbase_DEPENDS, mssql_DEPENDS and sybase_ct_DEPENDS which are actually no longer
in the tree. We should remove those.

-- 
You are receiving this mail because:
You are on the CC list for the bug.