In a discussion in Late August 2011 on ports@, after cups* ports flipped the default OPTION GNUTLS from on to off, users started complaining loudly on the lists due to the .if defined WITH_GNUTLS ... BROKEN="doesn't work with GNUTLS" situation. Meaning, cups* ports that built fine in their version 1.4.6 could no longer be built after update to 1.4.8. The OPTIONS framework had recoded the old GNUTLS=on setting which would break the new port version. Consequence: users had to manually reset the GNUTLS option before being able to upgrade CUPS. Only systems that had never had CUPS installed were unaffected.
This Wiki page tries to identify problems we see with the practical OPTIONS use, later assemble a list of requirements that a new system should fulsill, and after that, discuss a way there.
Issues with OPTIONS
- OPTIONS does not show default values, so in case of build troubles, users need to read the Makefile or "make rmconfig ; make config" to figure the defaults.
- portmaster/bsd.port.mk (b.p.mk for short) do not re-prompt the user if the DEFAULT has changed
Ideas not yet requirements
- The options system could offer an option where the user can say "reset to default" (static), or "I don't care about this option, go with the default" (dynamic)
Requirements for a new OPTIONS system
Please mark requirements no longer valid in strike-through, spelt --(strike-through)--, and add new ones at the bottom, so that the numbers remain stable
- The options system should track the port's former defaults alongside the user-selected settings, so as to be able to detect default changes.
- The options system should be able to operate with the base system facilities of all supported FreeBSD releases.
The options system should take system-wide (for instance /etc/make.conf) KNOBS like WITHOUT_NLS into account.
- The options system should still respect BATCH.
- The options system should still present an ncurses screen with the possible options in.
... (any non-functional requirements as to the operational speed?) ...