I mean the whole options fiasco in ports.
1. You can have an options file, which will be used to direct the package's build, which is installed in to /var/db/ports (by default) at the start of the build process. If you're trying to do unprivileged builds, this is painful. If you're not using sudo with a decent time limit for re-authentication (say by using su on a new machine) this is excruciating
2. The options file is installed into /var/db/ports/www_nginx/options and the file has the package build string embedded into it:
# This file is auto-generated by 'make config'.
# Options for nginx-1.10.3_1,2
_OPTIONS_READ=nginx-1.10.3_1,2
3. If the package version number does not match exactly what is recorded there, you will get a dialog box appearing
4. You can also embed options in the MAKECONF (on FreeBSD, it's /etc/make.conf). I could foresee issues with precedence here
5. We would now have to bootstrap dialog for menu provision in pkgsrc bootstrap. Not a biggie, just considering what else we'd have to do to apply this idea
6. In my experience, the BATCH thing hasn't worked in certain circumstances. It may have been fixed recently.
7. I can't count the number of times I've gone away from a FreeBSD machine and looked forward to a completed build by the time I came back, only to find that version numbers don't match, and that, instead, I have a dialog screen waiting for me
OK, so you'll admonish me for attacking the implementation, and not the idea itself. So a few questions:
1. How do you record the option requested by the user for posterity? In MAKECONF, in some form of dir hierarchy located where, and with which permissions?
2. Is this choice temporary (i.e. throw away after package is built) or long-term (i.e. record and all future builds will be done with this)? Should it be both or neither?
3. Should we preserve options across version changes with a dialog?
4. Should user input take precedence over MAKECONF, or MAKECONF over dialog?
5. I'd like to be able to run /etc on NetBSD as read-only, I don't want to record package options in any other place. I now have issues
6. A simple timeout might solve many of the frustrations I have with dialog. BUT how do you do option choice sanely in the presence of timeouts. Automation should work for me, and I shouldn't have to be checking up on it all the time.
In summary - our option choice is designed to be simple, and editable by anyone with an editor and privileges. We have found, in the past, that complexity causes issues. We assume some level of ability in most people using a packaging system; whether that is warranted or not. If someone knows enough to want HTTP_GZIP_STATIC in nginx, for example, we expect them to be able to edit a file to choose that.