last time I saw this behavior it was an issue with bsd.port.mk , so either there is a regression in some of the cleanup patches for indents, or something is wrong with portmaster. both have been getting updates over the period of time when things have gone haywire for me. first really noticed it when QT updated a few days ago and qt5-sqldrivers-sqlite3 kept failing and failing due to FLAVOR=default somehow being in the environment. It seems to be carrying this FLAVOR from the dependency on sqlite3. to be honest i expected this gdal to fail, but with the flavor of py39, but alas it was carried in seemingly from the dependency check not the upstream build. gdal had been removed during a previous failed upgrade it seems, so it was being built to satisfy py39-gdal's need of it. I honestly do not know if its portmaster or bsd.port.mk or some other piece of Mk/ wanted to post bug in case others are seeing this issue. I know when I did a rebuild after 13.1 update things worked as that was shortly after bsd.port.mk being patched to fix the carry of FLAVOR into the recursive makes. PR 256736 was still open on bsd.port.mk so I posted earlier of the possible regression. needed to do something after coming to terms with potentially having to manually upgrade KDE one port at a time. /usr/bin/strip /usr/ports/graphics/gdal/work/stage/usr/local/lib/libgdal.so ====> Compressing man pages (compress-man) ===>>> Starting check for runtime dependencies ===>>> Gathering dependency list for graphics/gdal from ports ===>>> The dependency for databases/sqlite3 seems to be handled by sqlite3-3.39.0,1 ===>>> Dependency check complete for graphics/gdal ===>>> py39-gdal-3.5.0 3/9 >> graphics/gdal (1/1) ===> gdal-3.5.1 FLAVOR is defined (to default) while this port does not have FLAVORS. *** Error code 1 Stop. make: stopped in /usr/ports/graphics/gdal ===>>> Installation of gdal-3.5.1 (graphics/gdal) failed ===>>> Aborting update ===>>> Update for graphics/gdal failed ===>>> Aborting update ===>>> Update for py39-gdal-3.5.0 failed ===>>> Aborting update
There was a commented out call of export_flavor() just before the failed invocation of "make". Seems that the FLAVOR of a dependency could "leak out" via the process environment, probably from the dependency check performed before the port is installed. The port will be updated to version 3.22 (already available from the master site).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f15fe3ba81d8235a209530b478507efd28fe29b4 commit f15fe3ba81d8235a209530b478507efd28fe29b4 Author: Stefan Eßer <se@FreeBSD.org> AuthorDate: 2022-07-08 11:38:43 +0000 Commit: Stefan Eßer <se@FreeBSD.org> CommitDate: 2022-07-08 11:38:43 +0000 ports-mgmt/portmaster: Fix an issue with flavored dependencies Flavored run dependencies of an unflavored port could cause the installation of the port to fail after it had been successfully built. This issue should be fixed by this update, which executes a previously commented out function call to update the FLAVOR in the environment of the make command used to install the port. I do not remember why I had commented out that function call, a long time ago - but I do not expect it to cause any regressions, since the same FLAVOR is now set enforced during "make install" as had been used to build the port. PR: 265084 Reported by: alt2600 at icloud.com ports-mgmt/portmaster/Makefile | 2 +- ports-mgmt/portmaster/distinfo | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
The problem with putting FLAVOR into the environment globally is that you don't have any control. Any other subsequently forked instance (and any children of that) will inherit that FLAVOR whether that FLAVOR is valid for any given dependency or not. This has broken certain port combinations where using that FLAVOR for the forked build of a dependency was clearly wrong. I would have to dig up an example unfortunately, but it caused a real failure. What I did locally to set FLAVOR more surgically is to just pass FLAVOR to the immediate next 'make install': --- portmaster.orig 2022-07-08 05:32:04.000000000 -0600 +++ portmaster 2022-07-21 09:59:32.242368000 -0600 @@ -3846,8 +3846,8 @@ if [ -z "$use_package" ]; then unset np_orphan # Defining NO_DEPENDS ensures that we will control the installation # of the depends, not bsd.port.mk. - export_flavor $(flavor_part "$portdir") - eval pm_make_s -DNO_DEPENDS install $port_log_args || install_failed $new_port +# export_flavor $(flavor_part "$portdir") + eval pm_make_s ${FLAVOR:+FLAVOR=$FLAVOR} -DNO_DEPENDS install $port_log_args || install_failed $new_port else [ -n "$local_package" ] && ppd=${LOCAL_PACKAGEDIR}/All That has worked out much better for me (locally patched for over a year at least). I meant to submit that upstream, but I didn't ever get around to it.
(In reply to John Hein from comment #3) Thank you for the suggestion and patch to conditionally add FLAVOR to the command line of "make install". Passing FLAVOR in the environment solved some (no longer remembered) issue in portmaster, though. The latest change made sure that the correct FLAVOR was set in the environment (and that FLAVOR is deleted from the environment in case of an unflavored port). But I do not see how "make install -DNO_DEPENDS" could recurs into other ports. Can you provide me with an example of a port that fails to be installed by portmaster with FLAVOR in the environment but succeeds with the patch applied? And: did you test whether your patch is still required in portmaster-3.22? I see that the patch you propose is relative to that latest version, but I guess you have just rebased your version and might not have checked whether it makes a difference in 3.22 ... The latest portmaster version removes FLAVOR from the environment in certain cases. But your patch optionally adds it to the command line and does not remove it from the environment (where it might be wrongly set). With your patch, if the FLAVOR exists in the environment (leaked out from some operation on some other port), it will be applied even if the port does not support flavors. If I apply your patch, I'll also "unset FLAVOR" before calling "make install" to prevent FLAVOR set in the environment from affecting the command. But as I said: there should be no recursion into other ports (-DNO_DEPENDS) and thus no difference between a FLAVOR passed in the enrvironment or on the command line.
(In reply to Stefan Eßer from comment #4) Like I said, I would have to dig up the example that this patch helped. It was a while ago. I'll see if I can find the problem case and whether the patch is still useful. By the way, in my local copy I also pass ${FLAVOR:+FLAVOR=FLAVOR} to 'make package' and some other places. I got rid of 'export_flavor' a number of other places - having a global FLAVOR in the environment has been fragile enough over the years that I avoided keeping FLAVOR in the global environment (by avoiding export_flavor). Things have been much better, but the prior failure cases were often complicated enough (updating lots of ports), that it was hard to identify a simple test case. That made it harder to report an reproducible upstream bug (and possible patch). If I can't find the failure case(s) from the past, I'll just start using the stock upstream version without local patches, and see if I can find some breakage again (or not).
(In reply to John Hein from comment #5) Please let me know of any issues you find. I have been just a portmaster user when FLAVOR support was added to the ports system and was only to be supported in poudriere. Since the original author of portmaster had left the FreeBSD project and I wanted to continue using portmaster, I have taken over the maintainer role and looked for a way to keep portmaster usable. I do not like the way it is implemented, but the way it is written made sense when it was created, more than 16 years ago (with no pkgdb, for example). It was a >4000 lines mostly linear shell script with global variables only, and I put a lot of effort into understanding it, using local variables and annotating global variables and variables to understand side-effects of functions. I do not remember the reasons for providing FLAVOR in the environment, but I seem to remember that there were cases were a FLAVOR on the command line caused issues, but passing it in the environment worked. I have actually been using a portmaster rewritten from scratch (first in sh, then bash to take advantage of associative arrays, now lua to allow for complex data structures and multi-threading) for more than 2,5 years. It has lots of additional features (e.g. can optionally build ports in a clean chroot jail), but my main goal was to speed it up by taking advantage of parallelism. A full scan of my ~2500 ports for updates takes less than 10 seconds, for example, and fetch, extract, configure, patch, build, package create, deinstall, and install phases of different ports can run in parallel. But it is surprisingly hard to get conflicts handling correct in such a parallel architecture, where the planning phase works on as many ports as there are CPU cores simultaneously. (Conflicts handling will always be imperfect, based on heuristics, anyway. But parallel scanning causes conflicts to be detected in a non-deterministic order, and conflicts handling decisions have an impact on the scanning that is to be performed. This issue can easily be circumvented by single-threaded scanning - but that's not what I want to do.) I hope to get these issues sorted out (without giving up parallelism) and will then make that version available as a port (it is already being maintained in a public repository on Github) ...