I keep /var/db/ports (or at least the options file therein) under revision control. After any update to ports when I am prompted to select or update options, I rsync the stored options into the repo and commit any changes along with reminders to my future self if I went with the maintainer's defaults or not, and sometimes why. The problem is that the order in which options are written to OPTIONSFILE is dependent on things that don't matter to the configuration management task, like (I guess) the order in which the maintainer wants options to appear in the config dialog. This often introduces superfluous diffs, which I would like to prevent. Fix: The attached patch teaches bsd.port.mk to use the ":O" variable expansion modifier when writing TMPOPTIONSFILE. Patch attached with submission follows: How-To-Repeat: Go look at /var/db/ports/*/options right now. Are the lines in alphabetical order by option? It depends. net/wireshark, x11/xorg-apps, ftp/wget, and devel/gvfs are likely candidates.
Responsible Changed From-To: freebsd-ports-bugs->portmgr bsd.port.mk is portmgr territory (via the GNATS Auto Assign Tool)
Responsible Changed From-To: portmgr->bdrewery I'll take it.
Is this PR still relevant?
cs: I'm not sure. I have begun managing port options mainly by setting category_port_SET=FOO and category_port_UNSET=BAR in make.conf which I feed to poudriere. In doing so I have given up the options dialog prompt I used to get when building ports with portmaster any time any port's options changed. Using poudriere means my /var/db/ports is probably completely irrelevant. To be precise, I've stopped paying attention to it, but this diff is still hanging out in my ports tree. The ability to use *_SET and *_UNSET means that I just record the options that I care about one way or another and let everything else follow maintainer defaults, which is a great improvement. However, I have not yet come back around to using a satisfactory method, asynchronous or by policy check, of detecting when available options change to drive discovery of A) an old option about which I used to care but can no longer, and B) a new option about which I may decide I care. Having said that, I doubt that /var/db/ports, or the lexicographic ordering of the OPTIONSFILEs therein, will end up having anything to do with that. Incidentally, why do you ask?
I ask because nobody has handled this PR for over a year. So, would you please try to get in touch with Bryan Drewery to commit the stuff -- if necessary. My goal is that this PR can be closed quickly. If Bryan has no time, we can give the PR back to pool.
The options are already sorted in bsd.options.mk, so, it is not needed.