If I run 'make config' for www/py-autobahn, select "OK" to save my options, then run 'make config-conditional', it runs to configuration dialog again. It is supposed to remember the initial config, so that 'config-conditional' does nothing. Other ports do not have this problem. Some side notes: (1) I notice that the Makefile for py-autobahn uses 'OPTIONS_FILE=${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options', which is very uncommon. It means the options are saved in /var/db/ports/www_py-autobahn/py38-options, rather than plain 'options' filename. However, changing this does not fix the issue for me, so I guess there is some deeper issue. (2) I experience this via my use of 'portmaster', but I do not think it is portmaster-specific, since that just runs the underlying 'make config-conditional'. The end result for me is that portmaster does all the options configuration upfront (good), but then re-runs the configuration during the actual build, for py-autobahn (bad!), adding more user-interactive prompts for builds that I would like to run unattended. No other port on my system behaves in this way. (3) I am not quite on latest yet (in process of upgrading my system), but I suspect this is still a problem since not much has changed in the port since my current rev 4ca4ff97d4dd (~2023).
`config-conditional` is not supposed to be called directly as it is not FLAVOR aware. The actual target is `config-recursive`. I am not aware about what `portmaster` is doing underneath.
(In reply to Muhammad Moinur Rahman from comment #1) Are you saying that the manpage for ports(7)[1] is wrong, somehow? It lists 'config-conditional' as a valid toplevel target (along with 'showconfig' et. al.). I'm not sure how to interpret your saying "...is not supposed to be called directly" when it is a documented target. [1] https://man.freebsd.org/cgi/man.cgi?ports(7)
Also, the fact that this only affects py-autobahn, and no other port (of 700+ on my system) seems to indicate that something is awry specifically with this one.
I said config-conditional cannot handle FLAVORS. So this will not be able to handle ports with FLAVORS. And to be frank for end users; ports is not the way to go. It's binary pkgs or poudriere for your custom builds. If you want to try ports/portmaster/portupgrade seek help from forums or mailing lists not as a bug report.
(In reply to Muhammad Moinur Rahman from comment #4) Okay, I will not re-open this, but just to be clear: plenty of other ports with FLAVORS do not exhibit this problem. For instance, every other python port I am using (which use PY_FLAVOR, same as py-autobahn), works just fine. And by that I mean this sequence: 1. # make config # shows options dialog 2. # make config-conditional # does nothing (already configured) works as expected. Only py-autobahn has this problem, where the options dialog is shown both times.
(oops, fixed status)
Okay, sorry to re-open once more, but after more investigation, I believe I've found the problem. The 'ASYNCIO' option for the port seems broken. In particular, it is not listed in the 'OPTIONS_DEFINE' list. Therefore, it is never displayed in the 'make config' dialog — even though the option exists, it is not settable by the user. As a result, it never saves the user's choice for that option (it always appears 'new' to the ports system), and this is why the original issue was happening - it keeps presenting the dialog box because it keeps thinking there is a new, unconfigured ASYNCIO option. I am not an expert on this port, but the options seem to be: 1. Add ASYNCIO to the OPTIONS_DEFINE list This fixes the issue for me, FWIW. I attached a patch, in case you want it as-is. 2. Get rid of the ASYNCIO option. As far as I can tell, it does not actually have any effect in this port. The last vestige of its being used was removed in 4884b761030295a, as far as I can tell. 3. Perhaps something more involved, rethinking how it interacts with the TWISTED option? I see that ASYNCIO is included in a OPTIONS_MULTI_BACKENDS, along with TWISTED. But then it is generally excluded from that list elsewhere in the port (eg: ${OPTIONS_MULTI_BACKENDS:NASYNCIO}). It seems silly to have such an option with only one entry. As a separate issue, I think it would be fine to get rid of the OPTIONS_FILE=... line, since I don't believe it does anything (but again: I'm not a ports expert). Anyway, I think there is real improvement to be made here, I hope you can commit it.
Created attachment 260251 [details] Fix ASYNCIO option handling for www/py-autobahn Attached patch. This was slightly more involved — I forgot that it does *need* to lose the OPTIONS_FILE line, since otherwise it was "${FLAVOR}-options}" was expanding to "-options" elsewhere in the ports makefile processing. Also needed to remove the odd handling of COMPLETE_OPTIONS_LIST and PORT_OPTIONS. Would very much appreciate a review / educated eye on it, though (:
(In reply to jwdevel from comment #0) This port has use of PY_FLAVOR but no flavors of its own that I could see. To me that makes the following look wrong and correctable: OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${FLAVOR}-options As I understand, that would use an empty FLAVOR definition, effectively: ${PORT_DBDIR}/${OPTIONS_NAME}/-options My guess at a correction for a possible original intent would be: OPTIONS_FILE= ${PORT_DBDIR}/${OPTIONS_NAME}/${PY_FLAVOR}-options It is possible that the content of what ${PORT_DBDIR}/${OPTIONS_NAME}/${PY_FLAVOR}-options should find needs manual editing/creation if the normal configure activity does not create such appropriately. Each PY_FLAVOR value to be used would have its own file to find. (Allowing for variability that might not put to actual use in the content of the files.) Note that you can test such by locally changing the www/py-autobahn/Makefile and then trying to use it. You may want to first see if ${PORT_DBDIR}/${OPTIONS_NAME}/*-options needs some sort of cleanout of results of prior activity. If you end up with a working context, you could then submit a buzilla requesting the specific textual change as something to be commited. I've not tested my hypothesis above. I use poudriere-devel and avoid live builds updating my systems as much as I can.
(In reply to jwdevel from comment #8) I would suggest not combining the different issues in one bugzilla entry, even if for the same port. In other words: I suggest having a separate bugzilla submittal for the ASYNCIO issue.
(In reply to Mark Millard from comment #10) In case it is not clear: I view getting the OPTIONS_FILE handling working as its own issue, even if both parts are needed to get ASYNCIO working overall.
(In reply to Mark Millard from comment #10, #11) > I suggest having a separate bugzilla submittal ... No problem — Created bug286664. The root issue (from my user POV) requires a fix to both the OPTIONS_FILE=... and ASYNCIO options handling; neither by itself fixes the 'make config-conditional' behavior. > both parts are needed to get ASYNCIO working overall. It may also be the case that ditching the ASYNCIO completely is a good choice. From my POV, the real thing to fix is the "make config-conditional" behavior. But yes; two parts of the same puzzle (: I defer on the ultimate best solution to people who know this port better.
(In reply to Mark Millard from comment #9) > If you end up with a working context, you could then > submit a buzilla requesting the specific textual > change as something to be commited. I put a patch on this bug that fixes it for me. Is there some other way to submit such a request (sorry, I'm unfamiliar with the process here) That aside, I did do some investigating with .info printouts that (1) it tries to include the wrong option filename: "/var/db/ports/www_py-autobahn/-options", whether it's FLAVOR or PY_FLAVOR in the Makefile, and (2) when I let it use the default filename, it finds the file okay, but the ASYNCIO option handling still causes the dialog to pop up each time since it always is treated as "new". Maybe I will try making a bigger patch, which does a larger cleanup of the whole TWISTED/ASYNCIO "backends" thing, which seems like it's over-wrought and unnecessary by this point in history.
(In reply to jwdevel from comment #13) For (1): Sorry my OPTIONS_FILE hypothesis was wrong. Apparently PY_FLAVOR is not defined when OPTIONS_FILE is actually used in the order things are done. I was already having to guess the original intent as well. I'd still claim that removing OPTIONS_FILE so that it uses the default file path matters for more than ASYNCIO and should be on its own as a proposed change. (Similarly if there is, instead, another definition of OPTIONS_FILE that should be used.) It would seem that what you are reporting for ASYNCIO is an issue that any somewhat analogous OPTIONS_MULTI use would have, not just ASYNCIO in this port. May be there should be some documentation about when OPTIONS_MULTI use should be avoided if it is not fixed ot also work. (I've no clue if any fix would be viable.) I'm not familiar with the port at all. So I'm not likely to try to add any more to this bugzilla.
Alright, so after some more work and realizations, it seems that the ASYNCIO option is actually fixed/removed in the latest version of the Makefile. So, that's a non-issue on latest. The only remaining issue is the OPTIONS_FILE line. It seems that removing that is the correct change - I had some back-and-forth on the forums[1] about this, and other people confirmed the issue on newer systems, and that removing that line fixed it So, seems like a one-line fix? I can make a patch if you want, but seems easy enough. [1] https://forums.freebsd.org/threads/help-with-strange-make-config-conditional-behavior.97774/
(In reply to jwdevel from comment #15) You may want to obsolete/delete your attachment so that it does does not lead to confusions.
(In reply to jwdevel from comment #15) Just an FYI: I looked up the history and the OPTIONS_FILE line was added back in: QUOTE author Kubilay Kocak <koobs@FreeBSD.org> 2019-06-03 13:06:46 +0000 committer Kubilay Kocak <koobs@FreeBSD.org> 2019-06-03 13:06:46 +0000 commit eb99ebbbecaa6024735ae94da9734c661e9ee494 (patch) tree 536c6cf9f1334bd565697bc0877b41d909db2025 /www/py-autobahn/Makefile parent bd94d2c38d67581f48a8fca462aea68821e4351e (diff) www/py-autobahn: Update to 19.5.1 Special shout out and thank you to Andrew aka RhodiumToad (IRC) for his support figuring out solutions to this sometimes crazy^W magical ports framework. Changelog: https://autobahn.readthedocs.io/en/latest/changelog.html Notes Notes: svn path=/head/; revision=503386 END QUOTE I do not see anything that would lead to FLAVOR being defined back then either. So far, I can not tell why it was added.
Let me be absolutely clear. This is not a bug in www/py-autobahn. The behavior you're observing is due to portmaster invoking `make config-conditional` without properly handling FLAVORS — which are a core part of the modern ports framework. This has already been explained in the initial comment comment #1, and confirmed through clean test environments using make recursive-config. The port behaves exactly as expected when used correctly. Even though portmaster is a tool intended to operate on ports, it is not exempt from the framework's expectations. The ports infrastructure defines the rules — including how OPTIONS and FLAVORS are handled. It is not the responsibility of individual ports to accommodate legacy tools that have not kept up. If a tool fails to comply with the framework, the bug lies in the tool, not in the ports it touches. Additionally, this bug was wrongly reopened based on speculation and commentary from forum members who demonstrably misunderstood the technical root cause. The ports tree is maintained according to actual reproducible behavior, not second-hand interpretations or unsupported conclusions drawn from mailing list lore or forum threads. This bug has already cost an entire day of developer time — not because it had merit, but because people chose to argue based on assumptions rather than reading the first comment or understanding the system. If you are still dissatisfied with the resolution: - Contact portmgr@FreeBSD.org (added here) if you believe the port violates project policy. - Contact conduct@ if you believe the closure was inappropriate. But this ticket is closed. Do not reopen it again. This matter is settled.
(In reply to jwdevel from comment #15) Not a reopening, just a confirming of details of the existing Makefile working for poudriere operation . . . I have confirmed what Muhammad reports. In essence that use of: poudriere options www/py-autobahn does lead to there being a: (note the py311) /usr/local/etc/poudriere.d/options/www_py-autobahn/py311-options with the option that I set for the test changed (COMPRESSION enabled): # This file is auto-generated by 'make config'. # Options for py311-autobahn-24.4.2_1 _OPTIONS_READ=py311-autobahn-24.4.2_1 _FILE_COMPLETE_OPTIONS_LIST=ACCELERATE COMPRESS ENCRYPTION SCRAM SERIALIZATION TWISTED OPTIONS_FILE_SET+=ACCELERATE OPTIONS_FILE_SET+=COMPRESS OPTIONS_FILE_SET+=ENCRYPTION OPTIONS_FILE_SET+=SCRAM OPTIONS_FILE_SET+=SERIALIZATION OPTIONS_FILE_SET+=TWISTED So the use of ${FLAVOR} in OPTIONS_FILE does work for poudriere(-devel) use. And, so, I learn something new to me about FLAVOR usage for python builds. Sometimes learning curves are messy. Sorry.