Bug 268383

Summary: net/yami4: Adopt and fix broken port
Product: Ports & Packages Reporter: Maciej Sobczak <prog>
Component: Individual Port(s)Assignee: Fernando Apesteguía <fernape>
Status: Closed FIXED    
Severity: Affects Some People CC: diizzy, fernape
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
The Patch
none
Complete tarball
none
Patch against 2022-12-18 none

Description Maciej Sobczak 2022-12-14 22:05:16 UTC
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
Comment 1 Maciej Sobczak 2022-12-14 22:08:16 UTC
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
Comment 2 Fernando Apesteguía freebsd_committer freebsd_triage 2023-01-24 07:16:06 UTC
Hi Maciej,

The port changed in between (version, USES=zip was added...) would you rework the patch to update it?
Comment 3 Maciej Sobczak 2023-01-24 19:01:49 UTC
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
Comment 4 Fernando Apesteguía freebsd_committer freebsd_triage 2023-01-25 06:30:05 UTC
(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.
Comment 5 Maciej Sobczak 2023-01-25 21:11:29 UTC
Created attachment 239709 [details]
Patch against 2022-12-18

The patch, updated to work against the most recent state from 2022-12-18.
Comment 6 Fernando Apesteguía freebsd_committer freebsd_triage 2023-01-26 12:13:23 UTC
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.
Comment 7 Fernando Apesteguía freebsd_committer freebsd_triage 2023-01-29 18:29:24 UTC
Hi Maciej,

Have you had a port before? I can't find any references in the tree or in bugzilla.

Cheers.
Comment 8 Maciej Sobczak 2023-01-29 18:54:55 UTC
Hi Fernando,

I am the original author of this port.
Comment 9 Fernando Apesteguía freebsd_committer freebsd_triage 2023-01-29 22:09:03 UTC
Committed,

Thanks! and welcome back :-)
Comment 10 commit-hook freebsd_committer freebsd_triage 2023-01-29 22:09:22 UTC
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(-)
Comment 11 Daniel Engberg freebsd_committer freebsd_triage 2023-01-29 22:31:41 UTC
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
Comment 12 Maciej Sobczak 2023-01-30 16:56:09 UTC
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