Bug 256301

Summary: bsd.port.mk: fix setting of FLAVOR in _FLAVOR_RECURSIVE_SH
Product: Ports & Packages Reporter: Andriy Gapon <avg>
Component: Ports FrameworkAssignee: Port Management Team <portmgr>
Status: Closed FIXED    
Severity: Affects Only Me CC: ports-bugs
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256736

Description Andriy Gapon freebsd_committer 2021-05-31 16:31:05 UTC
There are several ways of handling recursive targets.
I found at least

    Mk/Scripts/do-depends.sh
    Mk/Scripts/depends-list.sh
    _FLAVOR_RECURSIVE_SH

It looks that the latter has a couple of problems comparing to others.
First, it does not handle '@' in a port name.
Second, it would set FLAVOR to the empty value even if a package is not
"flavored". That can confuse some ports.

A fast demonstration of the second problem:

$ make -C /usr/ports/lang/gcc9 checksum-recursive
...
===>   native-binutils-2.33.1_4,1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by native-binutils-2.33.1_4,1 for building
...

Note how the package name is native-binutils instead of binutils.
A longer demonstration of the problem would be with the package-resursive target.

That issue was reported and analyzed some time ago, unfortunately with
no action: https://www.mail-archive.com/freebsd-ports@freebsd.org/msg84543.html

The proposed change brings _FLAVOR_RECURSIVE_SH closer to the other
recursion methods and it should fix both of the problems:
https://reviews.freebsd.org/D30579
Comment 1 Mathieu Arnold freebsd_committer 2021-06-01 07:15:02 UTC
Will fix with a slightly different patch.

Note that portmgr is not omnipotent, while we read ports@, it is possible we miss things.  For example, an mail thread that talks about lang/gcc9 does not strike me as something that I personally have any clue how to fix, it is for the lang/gcc9 maintainer.  If nobody notifies portmgr of a problem, and there was no portmgr member taking part of the discussion, there is a good chance we won't see it.

This is the reason we have a bug tracker, so that bugs get addressed to the right persons, and bugs don't get lost.
Comment 2 commit-hook freebsd_committer 2021-06-01 07:18:01 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=e70bedf4f71eda15307b550cefd028a5a4b0281a

commit e70bedf4f71eda15307b550cefd028a5a4b0281a
Author:     Mathieu Arnold <mat@FreeBSD.org>
AuthorDate: 2021-06-01 07:04:25 +0000
Commit:     Mathieu Arnold <mat@FreeBSD.org>
CommitDate: 2021-06-01 07:16:35 +0000

    Mk/bsd.port.mk: Don't pass up an empty flavor.

    The classic way to handle flavors is to set:

      FLAVORS= foo bar
      FLAVOR?= ${FLAVORS:[0]}

    And in that case, FLAVOR is only set if the variable is not defined. If
    you pass an empty flavor using `FLAVOR=` then it remains empty after
    that line.  It can leads to some ports with complicated logic to assume
    the wrong flavor is set.

    PR:             256301
    Reported by:    avg
    Differential Revision:  https://reviews.freebsd.org/D30579

 Mk/bsd.port.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 3 commit-hook freebsd_committer 2021-06-01 07:18:02 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=bad84b3403f35e38153b86976e46a29ea1c30c9b

commit bad84b3403f35e38153b86976e46a29ea1c30c9b
Author:     Andriy Gapon <avg@FreeBSD.org>
AuthorDate: 2021-06-01 07:02:35 +0000
Commit:     Mathieu Arnold <mat@FreeBSD.org>
CommitDate: 2021-06-01 07:15:49 +0000

    Mk/bsd.port.mk: Ignore @ in path in _FLAVOR_RECURSIVE_SH.

    While no port will ever have an @ in their path name, it might be
    possible that PORTSDIR has an @ somewhere in its path.

    PR:             256301
    Differential Revision:  https://reviews.freebsd.org/D30579

 Mk/bsd.port.mk | 1 +
 1 file changed, 1 insertion(+)
Comment 4 Andriy Gapon freebsd_committer 2021-06-01 07:21:26 UTC
Thank you very much!

Regarding that old thread, I actually expected that one of the participants would take a further action.  I would never get interested in that thread myself, it just happened that I hit exactly the same problem.  It seems that some of "-recursive" targets are not widely used these days.