Today I found the following: mutt-lite-1.10.1 ? orphaned: mail/mutt-lite This correlates with r481126: https://svnweb.freebsd.org/ports?view=revision&revision=481126 2018-10-01 mail/mutt-lite: For a lite version of mutt build mail/mutt with less (or zero) options Which makes no mention of the history or PR, which I had to dig up myself in r476197: https://svnweb.freebsd.org/ports?view=revision&revision=476197 Which claims "give users 2 months to move to mail/mutt". I saw absolutely no message/warning about this deprecation, which indicates that the implementation of said warning was done in such a way that **did not** take people using pkg (binary packages) into mind. Proof is here, indicating that only people who built from ports (source) would see this warning: https://svnweb.freebsd.org/ports/head/mail/mutt-lite/Makefile?r1=476197&r2=476196&pathrev=476197 Bug 229938 looks like the maintainer of the port decided to relinquish maintainership (which is 100% fine! It can go to ports@ in the meantime), and instead opted... for its entire removal?! What was done here is not good practise ports-wise; not everyone installs ports, most people use binary packages, which means "build mail/mutt with less or zero options" it not an option/choice available to them. It's scaring me how people don't seem to understand the relationship between ports and pkg. I don't know how any of this was permitted by portmgr; it is not common practise for port deprecation to work this way. Please either: a) Undo this change (probably not feasible given r476197), or, b) Create a stub port that includes fewer options as described. (This is exactly how tons of the *-lite, *-tiny, and *-nox11 ports work.)
I can resurrect port if you agree to maintain it, but I think you should talk to mail/mutt maintainer first, this port depends on ifdefs in the main port and would be useless without them.
I did take this into account when removing the port by using the total number of *-lite ports. There were very few *-lite (*-tiny and *-nox11 only adds a couple more) so I felt removing this was low risk thinking that *-lite ports were not as popular. Being this is the first PR and mailing list post (at least for mutt related items) I'd like to guess mail/mutt-lite isn't very popular at least for head ports or latest pkg users. The next test would be at the start of the quarterly release. It's possible the expiration date was just too low and should have been at least 4 maybe 6 months to get a better feel of mail/mutt-lite users. Looking at other ports deprecation reasons most are EOL/upstream related while some are "moved to cat/here." I feel this case would maybe be a flavor of the latter. Looking back a port revision bump should have happened such that forcing a rebuild of mail/mutt-lite such that a pkg upgrade would have installed a version of the package with the expiration and deprecation message either when installed or via 'pkg annotate -a -S deprecated' that runs on a nightly basis via pkg's periodic scripts. So yes it was a valid complaint that you didn't get any notifications if you already had 1.10.1 installed. I would rather not have a lite version of mutt and continue to support an option less install. However, if someone from portmgr@ feels this deprecation was done in error I'd be in favor of bringing mail/mutt-lite back either with a longer expiration date or a removal of the deprecation completely. Fortunately I wasn't going to do the LITE clean up on the main port until the next update of mutt. According to the mutt mailing list this is going to happen in ~2 weeks. So in theory if MOVED was updated and the old mail/mutt-lite port was brought back it should just work. Jeremy even though you're not using ports directly you can indirectly use ports via poudriere and add that local poudriere repo to your repo list. I understand this might not scale for some cases however it's an option if mail/mutt-lite wasn't brought back.
Thank you for the explaination. I'll wait and see what happens in 2-4 weeks. Any time I see a basic-functionality port orphaned, I research why it's being orphaned. I couldn't find any justification in commit messages, discussion of it on public mailing lists, etc.. All I found was what was in r476197, which was basically "maintainer requests removal". Maintainers have that right, absolutely, and I support that. But I asked myself as someone who has been a committer in the past: "was this stub port painful to maintain?" and looked -- no patches, in fact compared to some other stub ports, this looked remarkably basic: https://svnweb.freebsd.org/ports/head/mail/mutt/Makefile?revision=474967&view=markup#l48 https://svnweb.freebsd.org/ports/head/mail/mutt/Makefile?revision=474967&view=markup#l100 https://svnweb.freebsd.org/ports/head/mail/mutt/Makefile?revision=474967&view=markup#l108 This is when I discovered the Makefile shims for MUTT_LITE were left in place, which made this situation even more bizarre (to me). I thought: "why would someone deprecate a stub port yet leave the shims in place?" The best answer I came up with was "maybe the stub port is getting renamed, similar to how vim-lite got renamed to vim-console recently?" But I couldn't find anything of the sort. I don't want to complicate your life as a port maintainer. Really. I've just never seen this situation happen before -- orphaning yes, maintainers wanting to stop maintaining a stub or one-off yes, programs as a whole going the way of the buffalo yes, but not this situation in this manner. I'm fine with switching to mutt (from mutt-lite), but when doing so, I like to understand exactly why something that worked just fine has to be removed.
> I'll wait and see what happens in 2-4 weeks. > [...] > I'm fine with switching to mutt (from mutt-lite), but when doing so, I like to > understand exactly why something that worked just fine has to be removed. Since you are fine with using mutt and nothing happened in half a year here, is it reasonable to assume that we can close this bug?
FreeBSD: the power to serve.