A recent update to blender (bug #294160) requires devel/meson to be built for non-default Python 3.13 to build. To do so, I'll shortly add USE_PYTHON=allflavors to the port. Unfortunately, devel/meson and devel/meson@py313 conflict on install and even if USE_PYTHON=concurrent is supplied, they still conflict on share/polkit-1/actions/com.mesonbuild.install.policy. Please check what needs to be done to support full concurrent installation of different flavours of devel/meson.
USE_PYTHON=concurrent with this port, even without the polkit file in play, is not really supported. Consumers expect to find exactly bin/meson to execute, nothing else is accepted. Even meson-python, which otherwise uses the Python packaging system to detect its dependencies including meson itself, executes meson like every other consumer (when a package does not include and use a forked meson).
(In reply to Charlie Li from comment #1) So what's the best way to proceed here? Can we put a meson binary into some magic path or have a BINARY_ALIAS shim in USES=meson to work around this?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d0e08ee74bc97443bce5d03d899b74ce266f64d5 commit d0e08ee74bc97443bce5d03d899b74ce266f64d5 Author: Robert Clausecker <fuz@FreeBSD.org> AuthorDate: 2026-06-15 21:55:00 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2026-06-16 21:26:55 +0000 devel/meson: build for all Python versions (for graphics/blender) PR: 294160, 296086 devel/meson/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
devel/meson@"non-default-flavor" can't be installed on same live system with devel/meson@"default-flavor", but consumers can be build in poudriere using any flavors.
In the dependencies of devel/meson-python, it is necessary that it can be passed through as follows. -BUILD_DEPENDS= meson:devel/meson@${PY_FLAVOR} \ +BUILD_DEPENDS= meson-${PYTHON_VER}:devel/meson@${PY_FLAVOR} \ -RUN_DEPENDS= meson:devel/meson@${PY_FLAVOR} \ +RUN_DEPENDS= meson-${PYTHON_VER}:devel/meson@${PY_FLAVOR} \ Even if it gets through because of that, the next error pops up during the build. meson-python: error: meson executable "meson" not found I don't know how to forcefully specify the path to meson executable. And since I haven't looked into it, this is the end here :)
(In reply to Tatsuki Makino from comment #5) > I don't know how to forcefully specify the path to meson executable. That said, as a result of a little research: According to def _get_meson_command in ${WRKSRC}/mesonpy/__init__.py, it can be overridden by the environment variable MESON. If that's not done, the problem can be bypassed and things can continue if BINARY_ALIAS=meson=meson-${PYTHON_VER} is used in devel/meson-python/Makefile. Because of that, it seems that the environment where my py311 is the default version can reach the build of blender 5.1.0.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=182bca0e9fa24e91b4eea0b41e0f66badd90b537 commit 182bca0e9fa24e91b4eea0b41e0f66badd90b537 Author: Robert Clausecker <fuz@FreeBSD.org> AuthorDate: 2026-06-17 11:17:59 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2026-06-17 11:24:55 +0000 devel/meson: Revert "build for all Python versions (for graphics/blender)" Reverted as requested due to lack of approval by the python team. There's also a build problem in dependent ports due to USE_PYTHON=concurrent which requires additional detail work to address. PORTEPOCH bump as USE_PYTHON=concurrent changes the plist. Reported by: antoine Requested by: arrowd, mat PR: 296086 This reverts commit d0e08ee74bc97443bce5d03d899b74ce266f64d5. devel/meson/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
ports d0e08ee74bc97443bce5d03d899b74ce266f64d5 has been reverted following request by mat and arrowd. It would be nice if a solution for blender could be found as it's an important piece of software. Blender needs meson for Python 3.13 through devel/meson-python, which as I understand requires the precompiled bitcode files of meson, so we can't just use 3.11 meson. I would also appreciate more guidance on when it is appropriate to add allflavors to a Python port.
devel/meson-python/Makefile: BUILD_DEPENDS= meson:devel/meson \ RUN_DEPENDS= meson:devel/meson \ But build error: ===> Configuring for py313-meson-python-0.18.0,1 ===> Building for py313-meson-python-0.18.0,1 * Getting build dependencies for wheel... ERROR Missing dependencies: meson>=1.2.3 *** Error code 1
Yes, as I said in comment 1, the expected binary is exactly `meson`, nothing else. (In reply to Tatsuki Makino from comment #6) https://mesonbuild.com/meson-python/reference/pyproject-settings.html#cmdoption-arg-tool.meson-python.meson So theoretically Blender's pyproject.toml could be patched to add this setting to specify the correct meson executable. The environment variable overrides that setting. Otherwise this is normally used to specify a forked/vendored meson in the same source tree of a package, like with numpy. Because of existing legitimate use cases like numpy, the environment variable should never be specified for ports. However, I'm still not convinced for USE_PYTHON=concurrent here because the polkit file still exists. Have to consider that meson itself can be used outside of the ports context, on hierarchies that pkg(8) does not manage but still owned by a different user/group. polkit is another privilege escalation option that may be more suitable than sudo or other supported methods.
(In reply to Charlie Li from comment #10) The policy file installed by the port is no-op: it refers to /usr/bin/python3 and /usr/bin/meson.
(In reply to Charlie Li from comment #10) It seems that having leaf-port, like graphics/blender, take the initiative to use a newer version of python than the default helped in bumping default version of python :) Therefore, I am in the faction that believes preparations should be made for versions of Python that are not the default :) So, I think it's better if we can support all the flavors, even if it means creating ports like devel/pygobject-common. For example, when graphics/py-pycairo tries to install a flavor that is not default at the same time, file path conflict occurs, so I would like some kind of preventive measure. Also, it becomes somewhat troublesome when BUILD_DEPENDS of a port corresponding to all flavors include a port that only supports the default flavor. multimedia/openshot has now been committed with a state that includes a workaround for that problem. When writing depends by specifying the package name, if a downgrade of the flavor occurs, is it better to write it in that way?
(In reply to Tatsuki Makino from comment #12) Can't really apply this logic with meson due to the strict default expectations of consumers, particularly with only accepting exactly `bin/meson`. USES=concurrent will not help since consumers will not use or look for `bin/meson-${PYTHON_VER}`. (In reply to Tatsuki Makino from comment #6) BINARY_ALIAS only has effect during build; it is not kept in the resulting binary since the mechanism is a symlink created in a temporary $PATH entry.
(In reply to Charlie Li from comment #13) This is all very annoying. A better solution for concurrent Python installation has to be found. We can't just go tell people "Oh you want Blender? Well build all custom packages with a different Python default version and then maybe it'll build. Oh and if you need two packages that do not work with the same default Python version, well tough luck then."
(In reply to Robert Clausecker from comment #14) I agree with every word you said in this message! There was already a situation in the past when Python 3.8 and 3.9 (if I'm not confusing the versions) worked perfectly simultaneously on the same host.