Hello. My system FreeBSD 14.2-RELEASE-p2 amd64 My /etc/make.conf CPUTYPE?=nocona MAKE_JOBS_NUMBER=6 NO_GAMES=true NO_INET6=true NO_BLUETOOTH=true NO_SHAREDOCS=true OPTIONS_UNSET=DOCS X11 IPV6 BLUETOOTH GAMES SMB CUPS VULKAN FFMPEG GITWEB EXAMPLES How to fix? pkg-static: py311-wheel-0.45.1 conflicts with py311-wheel044-0.44.0 (installs files into the same place). Problematic file: /usr/local/bin/wheel-3.11 # pkg version -v | egrep 'py' py311-build-1.2.2_2 = up-to-date with index py311-flit-core-3.11.0 = up-to-date with index py311-installer-0.7.0 = up-to-date with index py311-packaging-24.2 = up-to-date with index py311-pyproject-hooks-1.2.0 = up-to-date with index py311-setuptools-63.1.0_3 = up-to-date with index py311-wheel044-0.44.0 = up-to-date with index python311-3.11.11 = up-to-date with index installation log portupgrade -arR ... ... ... => SHA256 Checksum OK for wheel-0.45.1.tar.gz. ===> Patching for py311-wheel-0.45.1 ===> py311-wheel-0.45.1 depends on package: py311-flit-core>=3.8 - found ===> py311-wheel-0.45.1 depends on file: /usr/local/bin/python3.11 - found ===> py311-wheel-0.45.1 depends on package: py311-build>=0 - found ===> py311-wheel-0.45.1 depends on package: py311-installer>=0 - found ===> Configuring for py311-wheel-0.45.1 ===> Building for py311-wheel-0.45.1 * Getting build dependencies for wheel... * Building wheel... Successfully built wheel-0.45.1-py3-none-any.whl ===> Staging for py311-wheel-0.45.1 ===> py311-wheel-0.45.1 depends on file: /usr/local/bin/python3.11 - found ===> Generating temporary packing list ===> Creating unique files: Move MAN files needing SUFFIX ===> Creating unique files: Move files needing SUFFIX Move: bin/wheel --> bin/wheel-3.11 Link: @bin/wheel --> bin/wheel-3.11 ====> Compressing man pages (compress-man) ===> Installing for py311-wheel-0.45.1 ===> Checking if py311-wheel is already installed ===> Registering installation for py311-wheel-0.45.1 as automatic [sites25] Installing py311-wheel-0.45.1... pkg-static: py311-wheel-0.45.1 conflicts with py311-wheel044-0.44.0 (installs files into the same place). Problematic file: /usr/local/bin/wheel-3.11 *** Error code 1 Stop. make[8]: stopped in /usr/ports/devel/py-wheel *** Error code 1 Stop. make[7]: stopped in /usr/ports/devel/meson *** Error code 1 Stop. make[6]: stopped in /usr/ports/devel/jsoncpp *** Error code 1 Stop. make[5]: stopped in /usr/ports/devel/cmake-core *** Error code 1 Stop. make[4]: stopped in /usr/ports/devel/cmake-core *** Error code 1 Stop. make[3]: stopped in /usr/ports/devel/re2c *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/re2c *** Error code 1 Stop. make[1]: stopped in /usr/ports/lang/php82 *** Error code 1 Stop.
Why don't you use 'pkg upgrade -f'? Just remove py311-wheel044, it's only a build dependency. There is no bug here that needs to be fixed.
Hello, it really looks like a bug to me, as a matter fo fact if you start with a clean machine and simply install portmaster and do "portmaster meson" you cannot even get meson working: following different dependency chains it tries to install both ports. I am sure it breaks other ports besides meson, too. The situation got worse after https://cgit.freebsd.org/ports/commit/devel/py-setuptools/Makefile?id=8b5ae17d2f43388fade30e266615a9e34bf06abd : two days ago one could work around this physically removing the "temporarily” added devel/py-wheel044, but now as it is an hardcoded build dependency of py-setuptools (which, again, is required to build meson) the workaround dows not work anymore. Thanks, A.
(In reply to Yuri Victorovich from comment #1) I'm seeing the same issue across a dozen different systems. Ports are being built with portmaster. OS: 14.2-release /etc/make.conf DEFAULT_VERSIONS=perl5=5.38 ssl=openssl python=3.11 python3=3.11 pgsql=16 Here's an example to trigger it. -------------- portmaster -d security/py-bcrypt Install security/py-bcrypt Install devel/py-build@py311 Install devel/py-flit-core@py311 Install devel/py-installer@py311 Install devel/py-packaging@py311 Install devel/py-pyproject-hooks@py311 Install devel/py-cffi@py311 Install devel/py-pycparser@py311 Install devel/py-setuptools@py311 Install devel/py-wheel044@py311 Install devel/py-wheel@py311 Install lang/cython@py311 <snip> ===>>> security/py-bcrypt >> devel/py-cffi@py311 >> devel/py-wheel@py311 (9/11) ===> Installing for py311-wheel-0.45.1 ===> Checking if py311-wheel is already installed ===> Registering installation for py311-wheel-0.45.1 as automatic [uwsgi16-01.test] Installing py311-wheel-0.45.1... pkg-static: py311-wheel-0.45.1 conflicts with py311-wheel044-0.44.0 (installs files into the same place). Problematic file: /usr/local/bin/wheel-3.11 *** Error code 1 Stop. make: stopped in /usr/ports/devel/py-wheel ===>>> Installation of py311-wheel-0.45.1 (devel/py-wheel@py311) failed ===>>> Aborting update ---------------- Can this bug be reopened?
(In reply to jSML4ThWwBID69YC from comment #3) Hi, in my opinion the fact that one can take a fresh machine, "pkg add portmaster" and then "portmaster <onlyoneport>" is the expected behavior. The "temporary" addition of py311-wheel044 broke this behaviour for dozens of ports, including very critical ones. I cannot see how this should not be considered a bug. Please, please, please: revert this and the change on py-setuptools, or fix it. Thanks! A.
Assign to vishwin because he added the devel/py-wheel044 port.
This change broke portmaster and other local build tools, as others complain. poudriere doesn't seem to be affected.
(In reply to jSML4ThWwBID69YC from comment #3) build devel/py-setuptools, remove devel/py-wheel044, proceed with you update.
Or you can always use poudriere. poudriere is a lot more reliable.
(In reply to Yuri Victorovich from comment #8) FWIW a me too here. I just unpacked releng-13.5: 13.5-RELENG FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty to create a ports-dev jail. An attempt to build devel/git within that resulted in the same error reported here. Because I didn't have the time to investigate. I simply performed pkg delete py311-wheel044 and continued my build session. This is a bug.
(In reply to Max Brazhnikov from comment #7) That functions as a workaround. However, the issue breaks every single automated build that has py-wheel in it. At least if you're using portmaster.
To portmaster users: you are welcome to come up with a patch to fix this problem. I'm pretty sure it will be committed.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d29fc7825c6e4d5a3e04355fbc72f6b957d15b22 commit d29fc7825c6e4d5a3e04355fbc72f6b957d15b22 Author: Yuri Victorovich <yuri@FreeBSD.org> AuthorDate: 2025-04-13 16:31:15 +0000 Commit: Yuri Victorovich <yuri@FreeBSD.org> CommitDate: 2025-04-13 16:34:06 +0000 devel/py-wheel{,044}: Add CONFLICTS_INSTALL PR: 285997 devel/py-wheel/Makefile | 2 ++ devel/py-wheel044/Makefile | 2 ++ 2 files changed, 4 insertions(+)
The fix might be to remove conflicting build-time dependencies before building any port. This can be achieved by using the CONFLICTS_INSTALL lines. I just added these lines to ports in question.
(In reply to Yuri Victorovich from comment #13) Thanks Yuri. That seems reasonable. Fingers crossed. :)
Created attachment 259541 [details] Patch The following patch seems to fix the issue for me.
Created attachment 259590 [details] Reproducible bug in clean environment
Created attachment 259591 [details] Problem reproduction log
(In reply to Yuri Victorovich from comment #13) Hello Yuri and thanks for the time you are dedicating to his. Unfortunately it seems that this did not solve the problem, and no, it is not a portmaster issue. Please find attached the console log on a "brand new and fresh machine" (a VM in which I simply installed a clean releng-14.2 base system and did not touch anything besides checking out /usr/ports from the current tree): a simple "make install", with no other ports installed, in /usr/ports/devel/meson fails due to this conflict. I am completely ignorant about python so I cannot contribute, what I can do overnight is to check if the patch proposed by Gleb Popov fixes it. Yes, it is a bug, it is breaking the build chain for several users (basically anyone who uses something that depends on python...), and IMHO it should not be closed. Thank you for your help, A.
In addition to other complaints, this breaks FreeBSD release building. Gleb, can you get your patch committed in the next 24 hours so this week's snapshot builds can happen?
(In reply to Colin Percival from comment #19) Can't guarantee 24 hours. Still reviewing this, but I don't like this workaround. Opens up a can of worms that I will explain in subsequent comments.
(In reply to Charlie Li from comment #20) Can we commit Gleb's patch as a temporary fix even if the final solution ends up being different? This week's snapshot builds start in about 8 hours and I'd really like to have them succeed.
I'm opposed to committing the patch as it stands at all. In general, the whole PYTHONPATH override just because a dependency has to be pinned is not something to be encouraged. Unfortunately dependency conflicts stemming from version pinning and bounding are a relatively common occurrence in the Python package world, for which (isolated) virtual environments have become essential to managing these between consumers. [0][1] This phenomenon is not limited to Python packaging. As a result, the whole ports mantra of running `make -C /usr/ports/foo/bar all install`, ie recursively building your whole dependency tree, and expecting it to Just Work is evaporating; it only works when the communities of everything we port actually respects this mantra. That said, I'm testing something where the whole of devel/py-wheel044 is moved under the setuptools vendor directory, to reflect the target consumer. This is only possible because setuptools (version currently in tree) has circular dependencies, and wheel is not already vendored as it is only needed when building under USE_PYTHON=pep517. Again, this port only lasts until bug 270358 can be committed. However, at some point we cannot continue to advertise recursively building an entire dependency tree without isolated environments (like poudriere, but certainly many other ways to do this), because the rest of the world has moved on and is not something we can necessarily control. [0] https://peps.python.org/pep-0704/ (itself withdrawn but context applies) [1] https://discuss.python.org/t/22846
(In reply to Charlie Li from comment #22) I agree in general, but isn't this specific case sort of special, for which we may make an exception? It is basically the same circular dep problem we saw with glib/gobject-intro, so we won't see these very often. Right now a lot of people are hit by this issue including re@, I feel bad about making them wait even more.
(In reply to Gleb Popov from comment #23) That's the problem, there are enough special cases in the wild that can eventually creep into our tree to the point where nothing is special. Making exceptions is simply not sustainable given where the rest of the open source world (and even commercial industry) is going and chooses to support. `make -C /usr/ports/foo/bar all install`, ie recursively building the whole dependency tree in the same runtime environment, simply does not make sense in today's world as it currently stands. Stand by for attachment.
Created attachment 259648 [details] setuptools/_vendor (apply with git-am) This moves the installed binary distribution under the setuptools vendor directory rather than ${PYTHON_SITELIBDIR}, with a .pth so the setuptools build can find it. Note that while this avoids the file conflict stemming from being in the same hierarchy, anything in ${PYTHON_SITELIBDIR}, including an existing devel/py-wheel, always takes precedence.
(In reply to Charlie Li from comment #25) It worked for my with my synthetic test, should also work for Colin.
Created attachment 259690 [details] Build log for devel/meson The last patch does not solve the problem. See attached log for a clean machine (14.2R) on which all that was done is: root@test:/usr/ports/devel/meson # history 1 pkg install git 2 cd /usr/ 3 git clone --depth 1 https://git.freebsd.org/ports.git 4 cd ports/devel/meson 5 make root@test:/usr/ports/devel/meson #
(In reply to Andrea Cocito from comment #27) You log says py311-wheel044-0.44.0 while it should say py311-wheel044-0.44.0_1 according to Charlie's patch.
(In reply to Gleb Popov from comment #28) My fault, I assumed it was on GIT already, after patching it compiles properly, thanks.
*** Bug 286261 has been marked as a duplicate of this bug. ***
(In reply to Charlie Li from comment #25) Charlie are you going to commit this?