Created attachment 252795 [details] Upgrade from 1.15.0 to 1.16.0 This is a maintainer upgrade of net-im/purple-gowhatsapp from 1.15.0 to 1.16.0 -- and catch up with the latest versions of the Go-packages we depend on. The actual changes are documented by the upstream author at the URL. This patch also adds the ONLY_FOR_ARCHS setting -- when I initially created the port, I expected the lang/go* ports to quickly add the capability to create shared libraries for FreeBSD's other architectures. Unfortunately, time goes on, but the capability remains available only on FreeBSD/amd64 -- and it is required for this port to build.
Maintainer informed via mail
1. USE_GITHUB= yep... ??? USE_GITHUB= yes 2. DB-backend => DB_BACKEND 3. portclippy: # USES block USES +DOS2UNIX_GLOB +USE_GITHUB +GH_ACCOUNT +GH_TUPLE USE_GNOME # USES=cmake related variables +CMAKE_ARGS -OPTIONS_MULTI -OPTIONS_MULTI_DB-backend -OPTIONS_DEFAULT # Make block +MAKE_ENV -$o_DESC -USE_GITHUB -GH_ACCOUNT -DOS2UNIX_GLOB # Standard bsd.port.mk variables EXTRACT_AFTER_ARGS # Options definitions +OPTIONS_DEFAULT +OPTIONS_MULTI +OPTIONS_MULTI_DB-backend -MAKE_ENV -GH_TUPLE # Options helpers +PGSQL_GH_TUPLE SQLITE3_GH_TUPLE -PGSQL_GH_TUPLE # Unknown variables # WARNING: # The following variables were not recognized. # They could just be typos or Portclippy needs to be made aware of them. # Please double check them. # # Prefix them with an _ or wrap in '.ifnmake portclippy' to tell # Portclippy to ignore them. # # If in doubt please report this on portfmt's bug tracker: # https://codeberg.org/tobik/portfmt/issues +$o_DESC -CMAKE_ARGS # Unknown targets post-patch-$o-off:
4. Sort options: USES= go:no_targets cmake dos2unix localbase:ldflags pkgconfig USES+= gnome gettext-runtime => USES= cmake dos2unix gettext-runtime gnome go:no_targets \ localbase:ldflags pkgconfig
You can fix the 4., but I don't see the first three as anything needing changing... Thank you!
(In reply to Mikhail T. from comment #4) "Every ports committer must follow the porter's handbook. It defines a set of rules and guidelines that we all must follow so that *all ports are written in the same way, and anyone can work on any port*." I can commit changes in 2 commits: 1) update port's version; 2) improve/standardization of Makefile.
> porter's handbook [...] defines a set of rules and guidelines that we all must follow Can you cite a rule -- or a guideline -- violated by USE_GITHUB=авжеж, for example? :-) > 1) update port's version; Yes, please. > 2) improve/standardization of Makefile. I don't mind sorting the options and other knobs, but I'll resent changes to $o_DESC or post-patch-$o-off, for example.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b53d4a4ceb19ddaf541194d77285f8711dba23c1 commit b53d4a4ceb19ddaf541194d77285f8711dba23c1 Author: Mikhail T. <freebsd-2024@virtual-estates.net> AuthorDate: 2024-08-19 15:47:42 +0000 Commit: Vladimir Druzenko <vvd@FreeBSD.org> CommitDate: 2024-08-19 15:47:42 +0000 net-im/purple-gowhatsapp: Upgrade 1.15.0 → 1.16.0 Changelog: - Feature: Offer to pair with 8-character code. - Feature: Video notes are received. - Feature: Have option to display message ID in conversation. https://github.com/hoehermann/purple-gowhatsapp/releases/tag/v1.16.0 PR: 280840 net-im/purple-gowhatsapp/Makefile | 26 ++++++++++++---------- net-im/purple-gowhatsapp/distinfo | 46 +++++++++++++++++++-------------------- 2 files changed, 37 insertions(+), 35 deletions(-)
Created attachment 252922 [details] v1: sort options, align lines, pet portclippy and portlint I like the design around $o_DESC and post-patch-$o-off, but I renamed $o with $_db.
Comment on attachment 252922 [details] v1: sort options, align lines, pet portclippy and portlint > but I renamed $o with $_db You renamed $o into ${_db} -- a multi-letter variable must be surrounded by braces in make -- which worsens the æstethics considerably :( Also, even though currently the only two options are, indeed, database-related, some day they may be of other kind -- which is why I'd prefer the more generic "o", for "option". The name of the multi-option is presented literally to the user -- and my original "DB-backends" is grammatically correct, whereas the new "DB_BACKENDS" is a perversion :( I know, you're trying to please portclippy et al, but I think, you're following it a little too blindly. The sorting of the options makes sense, but other changes are unappealing... Thank you!
(In reply to Mikhail T. from comment #9) > You renamed $o into ${_db} -- a multi-letter variable must be > surrounded by braces in make -- which worsens the æstethics considerably Disagree. "XXX${o}XXX" much better read than "XXX$oXXX". And "æstethics" is better too. > Also, even though currently the only two options are, indeed, > database-related, some day they may be of other kind -- which > is why I'd prefer the more generic "o", for "option". When that happens, I'll rename it to "_opt". > The name of the multi-option is presented literally to the user -- > and my original "DB-backends" is grammatically correct, whereas > the new "DB_BACKENDS" is a perversion :( Name of option "DB-backends" look strange. Anyway I added "DB_BACKENDS_DESC= Database backends" with good description. > I know, you're trying to please portclippy et al, but I think, > you're following it a little too blindly. No. I trying make port better. portclippy is just tool with recommendations. The port needs to be written in such a way that other developers don't waste time trying to figure out the intricacies that another developer has created. Large open source and commercial projects are not the place to show off your programming acrobatics. This should be done in personal, academic projects or programming contests. So if you have no other arguments, I insist on the proposed changes, aimed at improving the understanding of the port by other developers.
(In reply to Vladimir Druzenko from comment #10) > And "æstethics" is better too. A matter of taste. I would've thought, the final decision is mine -- as that of the port-creator and maintainer -- as long as it does not violate an existing rule. But I can no longer commit anything -- and you can. > I insist on the proposed changes Then change maintainership and do whatever you please with this bikeshed. Thank you for your time.