mutt @1.6: make it obsolete in favor of neomutt

[lbschenkel (Leonardo Brondani Schenkel)]

A new port neomutt was introduced to MacPorts recently which is based on a newer mutt version and contains all the patches from this port (and more). Because the NeoMutt project is maintaining all these patches, they don't conflict with each other and they are kept up to date so they apply cleanly over the latest Mutt version — two problems that this port currently have and make it very cumbersome to maintain. This port also has issues of opportunistic linking to libraries that are not declared in the Portfile, which has been fixed in neomutt as well.

It makes little sense to maintain both ports now since neomutt is a strict superset of mutt and we can piggyback on the work of NeoMutt project, so I'm proposing making mutt obsolete and focusing the effort on neomutt instead.

[ryandesign (Ryan Carsten Schmidt)]

The replaced_by line needs to appear before the PortGroup line for it to work correctly.

[lbschenkel (Leonardo Brondani Schenkel)]

Updated patch.

[neverpanic (Clemens Lang)]

Committed in r152967, thanks.

[vkuznet (Valentin Kuznetsov)]

I don't understand why you asked to make mutt obsolete. Why not to make neomutt as individual project. Sometimes we don't want to stay on bleeding edge. I want to try it but I don't want to overwrite existing mutt. What if my settings in mutt will not work in neomutt? I can raise many questions. Also, I want to try out next stable version 1.7 separately. I think making neomutt overwrite mutt itself is wrong approach since they can nicely coexists and give users flexibility to choose, try out and experiment with both.

[vkuznet (Valentin Kuznetsov)]

Or at least make a mutt_select which will allow to use either neomutt or mutt. I prefer this option.

[neverpanic (Clemens Lang)]

The point is that somebody needs to maintain vanilla mutt. None of the people in this ticket who are willing to maintain neomutt want to spend the additional effort to maintain a largely similar mutt port, especially with the amount of patches and variants that we used to have on mutt. Especially the various patches were always a headache to update for any new mutt version, but that work is now done in neomutt for us.

If you volunteer to maintain the mutt port in MacPorts, I'm happy to accept and commit a patch that restores mutt to a vanilla version. It was just my impression that there are not that many users that use mutt without any patches.

Note that when restoring the mutt port, you should probably port r152935 from the neomutt port, because that fixes a couple of issues with the build reproducibility of mutt.

Also, remember that you can always re-activate an old version of the mutt port before it was replaced_by neomutt if you're not willing to adjust your configuration right now.

[lbschenkel (Leonardo Brondani Schenkel)]

Hi Vkuznet,

I am sympathetic to your concerns. However, I think your concerns are more theoretical than real. NeoMutt is supposed to be a strict superset of Mutt, so all features in Mutt are present in NeoMutt and they have not been changed in any way. What NeoMutt does have is additional features that Mutt still does not have (but the intent of the project is to upstream all patches) — if you don't use them you won't even know they're there because they should be invisible to you. NeoMutt for you should work the same as vanilla Mutt 1.7.

Note that other mutt packages such as the one in Debian incorporate a number of patches, including many from NeoMutt. I believe most distros don't provide vanilla Mutt because it didn't have any stable release for a long time — development has just been picked up this year. This does not seem to affect or break most people's workflow.

Of course, nothing is perfect and there may be something in NeoMutt that breaks things for you. Please try it out and let us know if there are any. With that information in hand we'll be more informed to make future decisions.

To alleviate some of your concerns, I do plan in the future to add more variants to neomutt and allow disabling all patches that can be disabled by the configure script. Hopefully that will make the resulting build close enough to vanilla Mutt to make more users happy. I would like to stress that this level of configuration is not available in many distros and it does not seem to be a problem in practice — and once again, even with all patches enabled NeoMutt should not diverge from Mutt if you're only using features present in Mutt. Please do report if it's not the case.

[vb@…]

One problem is that neomutt has a very long startup time compared to mutt itself. I don't know why, perhaps there is a solution. But this makes me hoping to get mutt back.

[lbschenkel (Leonardo Brondani Schenkel)]

There is a patch on #52267 for a vanilla Mutt that I have submitted and it is free for the taking. Somebody should step up to be the maintainer of a revived Mutt port, though.