Bug 215542

Summary: ports-mgmt/portmaster: (r428604) mishandles USE_GCC=any context when lang/gcc6-devel is already installed, for example
Product: Ports & Packages Reporter: Mark Millard <marklmi26-fbsd>
Component: Individual Port(s)Assignee: Stefan Esser <se>
Status: Open ---    
Severity: Affects Only Me CC: gerald, tz
Priority: --- Flags: vlad-fbsd: maintainer-feedback? (tz)
Version: Latest   
Hardware: Any   
OS: Any   

Description Mark Millard 2016-12-25 01:21:34 UTC
This note uses lang/gcc6-devel and lang/gcc6 vs. ports-mgmt/postmaster
as an example of a more general issue. Another port having USE_GCC=any
in use was involved and I had lang/gcc6-devel already installed (and
no other lang/gcc* ). lang/gcc6-devel has been installed via

The issue is tied to both of those lang/gcc6* 's install gcc6 . If one
is installed already the other should not be attempted: they conflict.

ports-mgmt/portmaster tried to install lang/gcc6 instead.

First I'll quote wha the gcc6 maintainer Gerald Pfeifer wrote about
the expected build environment behavior in a message-list exchange that
we had:

USE_GCC=any is the equivalent of USE_GCC=4.2+, and lang/gcc6 and
lang/gcc6-devel should both meet this requirement.
. . . (omitted interlaced material from me) . . .
That works as designed.  USE_GCC=yes defaults to lang/gcc.  USE_GCC=any 
tries to use an existing GCC system compiler and lang/gcc by default if 
none is present.
. . .
It means gcc6 from lang/gcc6-devel is found
and identified as a suitable version of GCC.
. . .
Then Mk/bsd.gcc.mk adds

BUILD_DEPENDS+= gcc6:lang/gcc6

when it resolves USE_GCC=any.

That should not trigger and pull in lang/gcc6, though, as long
as gcc6 is found.

But what I found for this context was that using postmaster
was that it checks via:

pkg query %n-%v lang/gcc6

and never via:

pkg query %n-%v gcc6

(or anything based on just gcc6 or on lang/gcc6-devel that had
been used for installation of gcc6 ).

In essence the USE_GCC=any lead to use of the wrong "origin" for
gcc6 despite prior portmaster use to install gcc6 via gcc6-devel.

From the "pkg query %n-%v lang/gcc6" test result portmaster is
programmed to try to install lang/gcc6 even if gcc6 is already

The attempt fails because of conflicts between lang/gcc6-devel and
lang/gcc6 . (The conflicts are expected/required.)

I temporarily edited portmaster to use "sh -x" so that its execution
could be observed in detail and logged. The relevant part was:

+ pm_cd /usr/ports/lang/gcc6
+ builtin cd /usr/ports/lang/gcc6
+ grep -ql ^CONFLICTS Makefile
+ origin=lang/gcc6
+ iport_from_origin lang/gcc6
+ local sn dir
+ [ -n yes ]
+ pkg query %n-%v lang/gcc6
+ return 1
+ iport=''
+ check_exclude lang/gcc6
+ [ -n '' ]
+ return 0
+ [ -n '' -a -n '' ]
+ [ -n '' -a -n '' ]
+ [ -n '' ]
+ check_interactive lang/gcc6
+ [ -n '' ]
+ return 0
+ update_port lang/gcc6
+ local deps
+ [ -n '' ]
+ [ -z '' ]
+ echo '===>>> Launching child to install lang/gcc6'
===>>> Launching child to install lang/gcc6
+ dep_of_deps=2
+ [ -n pm_first_pass ]
+ [ ! '(' -n '' -a -n '' ')' ]
+ num_of_deps=2
+ deps='(2/2)'
+ term_printf ' >> devel/kBuild >> lang/gcc6 (2/2)'
+ echo -e '\n===>>> emulators/virtualbox-ose-additions >> devel/kBuild >> lang/gcc6 (2/2)'

===>>> emulators/virtualbox-ose-additions >> devel/kBuild >> lang/gcc6 (2/2)
+ [ -n '' ]
+ printf '\033]0;portmaster: emulators/virtualbox-ose-additions >> devel/kBuild >> lang/gcc6 (2/2)\007'
ESC]0;portmaster: emulators/virtualbox-ose-additions >> devel/kBuild >> lang/gcc6 (2/2)^G+ [ -n doing_dep_check -o '(' -n '' -a -n pm_first_pass ')' ]
+ [ -z '' -o -n pm_first_pass ]
+ sh -x /usr/local/sbin/portmaster -D -K lang/gcc6
+ trap trap_exit INT

(So devel/kBuild was what was using USE_GCC=any in my specific example.)
Comment 1 Torsten Zuehlsdorff freebsd_committer 2017-12-08 14:09:23 UTC
Hand over PR to new Maintainer of portmaster :)
Comment 2 Stefan Esser freebsd_committer 2017-12-18 19:02:15 UTC
I plan to completely rewrite the upgrade strategy routine to use explicit state instead of the state implicitly encoded in a large number of global variables.

Dependency tracking will also need to be re-implemented, and I'll keep this special case in mind.