I installed emacs with "cd /usr/ports/editors/emacs; make FLAVOR=nox install" and also have "DEFAULT_VERSIONS+=emacs=nox" in /etc/make.conf. The only options set in the emacs port are SOURCES and KQUEUE. However, doing a subsequent "portupgrade -f emacs-nox" proceeds to (apparently) build the regular (not "nox") flavor, as over a dozen X-related ports were built and installed before the build paused to ask me to select config options for graphics_gdk-pixbuf2. At that point I ^C'd the build and proceeded to clean up the leftover mess. My local ports tree is at r462474, kernel+world is at r329696 (11-STABLE, amd64) P.S. Isn't FLAVOR=nox redundant with OPTIONS_FILE_UNSET+=X11 (and friends)?
Unfortunately portupgrade does not support flavors (yet?). Your options for flavors are: using the default packages or building your own with one of poudriere, synth, portmaster, or directly with make. Also, "DEFAULT_VERSIONS+=emacs=nox" in /etc/make.conf is not for Emacs itself, but for ports using Emacs. That is, if a port depends on Emacs, it will pull in the default flavor of editors/emacs unless you either specify a flavor or add a value to DEFAULT_VERSIONS as you have. The nox flavor was redundant with the X11 option, so the X11 option was removed. But, in general, flavors are not redundant with OPTIONS_UNSET. With flavors you get multiple packages from one port. So, a benefit is that users with different requirements should not have to compile their own packages as often. If anything, flavors may have some overlap with slave ports, but in my option, slave ports can be a pain to work with.
(In reply to Joseph Mingrone from comment #1) Not directed at you, but flavors in general: Great, another solution in search of a problem, that doesn't interoperate properly with a major component of the ports system (and portupgrade doesn't respect "pkg lock" - see PR217339 from a year ago), meaning that "portupgrade -a" can't be used without risking pollution of the system with unwanted ports or building a port with the incorrect flavor/options. You say "The nox flavor was redundant with the X11 option, so the X11 option was removed." The X11 option is still in there (just do a "make config" to see it). If it still worked, there would have been no need for this PR. Can you re-connect "OPTIONS_FILE_UNSET+=X11" in the Makefile so the port can be told to not build the X11 version regardless of flavor, until portupgrade catches up with flavors?
Flavors, like in OpenBSD or Debian, have been requested for a long time. Many users simply do not want to compile their own packages. Now they can get different package flavors without compiling. I understand it is frustrating when a tool you have invested in lags behind, but there are limited development resources and those resources have been invested in tools like poudriere. If you want to build your own packages, I recommend poudriere. It builds in a clean environment. This leads to much fewer errors from the many uncontrolable variables that can pop up on live systems. If poudriere is not your cup of tea, then maybe the simplest solution (no external tools required) is something like make -C /usr/ports/editors/emacs FLAVOR=nox config-recursive reinstall If you update your ports tree you will see the X11 option is gone.
(In reply to Joseph Mingrone from comment #3) Rather than ranting further, I'd just like to point out that other ports (such as devel/py-setuptools) apparently manage fine with flavors and portupgrade. I just did a "portupgrade -f" and it correctly used the correct flavor and did the right thing. Since the editors/emacs port registers itself as "emacs-nox-25.3_3,3" I'm not sure why the flavor information isn't getting passed to the port Makefile and doing the right thing. Is that something you can look into, possibly comparing with devel/py-setuptools? Regarding the part about the X11 option being removed, if you look in SVN you'll see that the option is still present. It just doesn't seem to be connected to anything sometime after r460621 (that built fine, without dragging in all of the X11 components - it just complained about WITHOUT_X11 being unsupported).
(In reply to Terry Kennedy from comment #4) I just found and read through https://reviews.freebsd.org/D13506 and it looks like this issue came up repeatedly, with various things added / removed / changed to try to accommodate various usage situations. It is not clear to me what the eventual resolution was, since things went back and forth. To boil this comment down to a single question: Is there something I can put in make.conf to have the emacs port default to building the nox version? If there is, then portupgrade should "just work" as the port itself will default to the nox flavor.
(In reply to Terry Kennedy from comment #4) devel/py-setuptools manages fine with portupgrade and flavors, because you are installing the default flavor in that case. The X11 option is gone. You need to update your ports tree. See https://svnweb.freebsd.org/ports/head/editors/emacs/Makefile Maybe you could try something like this in make.conf? I have not tested this and while it may work for tools that support flavors, my guess is that it will not help with portupgrade. .if ${.CURDIR:M*/editors/emacs*} FLAVOR=nox .endif
(In reply to Joseph Mingrone from comment #6) No, it really isn't gone. It doesn't work properly any more, but a "make config" will show it. Go look at OPTIONS_DEFINE in https://svnweb.freebsd.org/ports/head/editors/emacs/Makefile?revision=462412&view=markup to see for yourself. If you do a "make FLAVOR=nox config" you won't see it, but if the flavor defaults to full you'll see it is still there. After all that discussion in D13506, we're still left with no simple way to preserve the existing functionality despite it being specifically mentioned several times there (and changes apparently were at least suggested) that handled this use case? Your CURDIR trick works for both "make" in the editors/emacs directory and when doing a "portupgrade -f emacs\*" from my home directory, so I guess you could call this issue "fixed" if you want. Up to you if you want to close or continue.
Ah, yes it was effectively gone, but another change had overwritten the removal from OPTIONS_DEFINE and OPTIONS_DEFAULT. Thanks, I will fix that shortly. As you can see from the Phabricator thread a mechanism for default flavors was suggested, but there are some issues to overcome. See the posts between Jan 16 2018, 10:26 AM and Jan 17 2018, 7:31 AM (my timezone).
A commit references this bug: Author: jrm Date: Wed Feb 21 12:46:19 UTC 2018 New revision: 462497 URL: https://svnweb.freebsd.org/changeset/ports/462497 Log: editors/emacs: Remove X11 option references missed in 462411 PR: 226083 Reported by: Terry Kennedy <terry-freebsd@glaver.org> Differential Revision: https://reviews.freebsd.org/D14233 Changes: head/editors/emacs/Makefile
Any change to allow a default flavor for individuals ports (other than the method suggested here) would be implemented outside of the Emacs ports, so I will close this.
You may want to update your entry in make.conf to this. .if ${.CURDIR:M*/editors/emacs*} FLAVOR=?nox .endif I noticed some issues with the other entry ('=' instead of '=?'). They were in poudriere, but it would be helpful to know if this entry works universally.
Sorry. That should have been this. .if ${.CURDIR:M*/editors/emacs*} FLAVOR?=nox .endif
(In reply to Joseph Mingrone from comment #12) That works (with a simple "portupgrade -f emacs\*").