Created attachment 238800 [details] The Patch The attached patch fixes the broken port and updates it to refer to the newest release of the upstream package. The new version has more install options, too. The patch was created this way, against the most recent state: cd /usr/ports/net diff -ruN yami4.old yami4 > net_yami4.patch Regards, Maciej Sobczak
Created attachment 238801 [details] Complete tarball The patch rewrites almost everything, so it might be more convenient to review the complete tarball. It was created this way: cd /usr/ports/net tar cf net_yami4.tar yami4
Hi Maciej, The port changed in between (version, USES=zip was added...) would you rework the patch to update it?
Hi Fernando, Thank you for picking up this bug fix. If you refer to the commit that was made few days after I have created this fix (that is, commit date 2022-12-18), then no, it was still misguided, as it tried to use the upstream version 1.12.0, which is still not was is intended. The current upstream version is 2.0.0. My patch is up to date with upstream and since it would still rewrite almost everything in the port, the complete tarball (already attached) is the most convenient way to proceed. Regards, Maciej Sobczak
(In reply to Maciej Sobczak from comment #3) Hi Maciej, What I mean is that your patch attached to this PR does things like: +USES= zip While *currently* in the repo, this port already does that. That's why I ask if you could rework the patch. It does not apply right now.
Created attachment 239709 [details] Patch against 2022-12-18 The patch, updated to work against the most recent state from 2022-12-18.
Thanks for the patch, I'll have a look. Note that PORTREVISION is not needed since there is a PORTREVISION bump. No need to update a new patch.
Hi Maciej, Have you had a port before? I can't find any references in the tree or in bugzilla. Cheers.
Hi Fernando, I am the original author of this port.
Committed, Thanks! and welcome back :-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3fab77d970d381cd1ec6924d5fd4a989122b9d1e commit 3fab77d970d381cd1ec6924d5fd4a989122b9d1e Author: Maciej Sobczak <prog@msobczak.com> AuthorDate: 2023-01-26 12:11:08 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2023-01-29 22:04:31 +0000 net/yami4: Update to 2.0.0 and set new maintainer Maintainer has no more ports, but was the original creator of this one. PR: 268383 Reported by: prog@msobczak.com net/yami4/Makefile | 55 +++-- net/yami4/distinfo | 6 +- net/yami4/pkg-descr | 5 +- net/yami4/pkg-plist | 610 ++++++++++++++++++++++++++++++++++++++++++++++++---- 4 files changed, 611 insertions(+), 65 deletions(-)
Hi, I have a few questions about this port. Do we really need to set 3.9 only? References should use variables not hardcode version number The if section isn't correct should be converted to YAMI4PYTHON_USES= python:3.9 https://cgit.freebsd.org/ports/tree/net/yami4/Makefile?id=3fab77d970d381cd1ec6924d5fd4a989122b9d1e#n60 See https://docs.freebsd.org/en/books/porters-handbook/book/#options-use USE_LDCONFIG is seems to be missing for python option? Is it intentional that cpp libraries are static and not shared? Best regards, Daniel
Hi Daniel, Thank you for your questions. I was daunted by the number of different Python versions available in ports and did not want to make this port more complex than necessary by introducing even more parameters or options. The 3.9 was chosen as a "likely and safe default" (which might change as the world evolves and other versions become prevalent) for those users who need trouble-free installation from ports. The upstream package was deliberately prepared for clean compile on FreeBSD, so users willing to use any other Python version can do that without additional effort directly from sources. An important factor in this choice was also the fact that even though I am confident in the C++ part to be relatively compiler-agnostic, I have less confidence in the multitude of Python versions. The 3.9 is the one that was tested. I get the point about variables instead of hardcoded values, but with single version (which is also displayed on the dialog window when configuring the package) the additional parameters would make the port less readable with little added value. Note that even with this fixed choice, there is "3.9" and "39" used in the Makefile, which already calls for two variables instead of just one. Is it worth the trouble? Is the added configurability worth the complexity? I am not arguing here, but honestly asking for advice. The Handbook, in the 5.14.3.2 section, does not say that one variant is more "correct" than the other. It explicitly says that they are equivalent, so apparently the choice is left to maintainers. I have chosen the variant that was more clear to me and that uses less "magic". What is the purpose of USE_LDCONFIG here? How would it help? Or, what do we miss by not having it? Last but definitely not least, the choice between static and shared libraries is a subject for never-ending debate. My recommendation is to go static except for system-base libs like language runtimes, although there is no technical constraint in the YAMI4 library itself that would influence that choice. Obviously, the Python module is shared. Regards, Maciej