If the EMACS option is set when building mail/mailutils, poudriere rightly complains: These packages depend on each other: mailutils-3.5 emacs-26.1_4,3
Maintainer informed via mail
Maintainer: please correct Mailadress CC: zeus@gnu.org.ua did not match anything
CC committer (danfe@) of ports r430016 which added the EMACS option Note: MAILUTILS is an option, enabled (ON) by default (OPTIONS_DEFAULT) in editors/emacs
CC committer (jrm@) of ports r471190 - MAILUTILS added to OPTIONS_DEFAULT in editors/emacs
Having editors/emacs and editors/emacs-devel depend on mail/mailutils by default matches upstream's default installation. Ideally we keep things as they are with the Emacs ports, otherwise Emacs can retrieve mail insecurely. Turning the option off by default does not seem like a complete solution and mail/movemail does not depend Emacs by default.
See https://reviews.freebsd.org/D22351 zeus@gnu.org.ua (or anyone else interested), please add yourself as a reviewer. I couldn't find a Phab account for you.
(In reply to Joseph Mingrone from comment #6) I added a comment in the review. The gist is that I vote for just removing the EMACS option. And always install the .el file if MH is on (and remove any [very marginally useful] .elc that might get installed for ease of managing pkg-plist).
See my response on the review.
Created attachment 209147 [details] [patch] remove EMACS option, install .el link if MH is on Based partly on jrm's patch from the phab review, attached is a slightly different take that just removes the EMACS option and installs the .el link if MH is on. This fixes the circular dependency and simplifies the OPTIONS list. I don't know a good way to add this in the phab review without causing confusion with this partial patch (since the review also covers a mailutils update). Joseph, integrate this with your patch in phab if you would like to. Part of that depends on whether danfe is okay with removing EMACS (or putting it another way, consolidating it under the MH option). This works whether emacs is installed or not. The only reason emacs would be used in the build, as far as I saw, is to create the .elc file. This patch just avoids the .elc byte compiled file. The .el is very small and having a .elc shouldn't help the user in any noticeable way. This slightly changes a package built with MH, so a PORTREVISION bump is called for unless this is merged with the update to 3.8
(In reply to John Hein from comment #9) > This fixes the circular dependency and simplifies the OPTIONS list. > Part of that depends on whether danfe is okay with removing EMACS > (or putting it another way, consolidating it under the MH option). Sure, that's fine with me. Less options is always good if they don't pull external dependencies. > This slightly changes a package built with MH, so a PORTREVISION bump > is called for unless this is merged with the update to 3.8 I guess it's OK to do this together with the update (and avoid port revision bump); the diff still remains of readable and manageable size. That said, I'm still waiting for the general feedback from the maintainer.
A commit references this bug: Author: jrm Date: Sun Nov 24 18:44:00 UTC 2019 New revision: 518346 URL: https://svnweb.freebsd.org/changeset/ports/518346 Log: mail/mailutils: Update to 3.8; fix circular [1] / missing dependencies - Remove the build dependency on Emacs since the installed elisp file is simple and does not need to be byte compiled. - Collapse the EMACS option in to the MH option [2]. PR: 235890 Submitted by: John Hein <jcfyecrayz@liamekaens.com> [2] Reported by: John Hein <jcfyecrayz@liamekaens.com> [1] Reviewed by: John Hein <jcfyecrayz@liamekaens.com> Approved by: danfe, Zeus Panchenko <zeus@gnu.org.ua> (maintainer) Differential Revision: https://reviews.freebsd.org/D22351 Changes: head/mail/mailutils/Makefile head/mail/mailutils/distinfo head/mail/mailutils/files/git-018df5d head/mail/mailutils/files/git-113e144 head/mail/mailutils/pkg-plist
Committed. Thank you all.