mutt @1.6.0 make it 'vanilla' and upgrade to 1.7

[lbschenkel (Leonardo Brondani Schenkel)]

It's hard to maintain the mutt port today because it contains on a lot of external patches that need to be refreshed for every new version and some of these patches conflict with each other, so they can't be used together.

It is much easier to rely on the work of the ​NeoMutt project since it maintains a number of the most popular patches cleanly applied over the latest release of Mutt. A port for it was submitted on #52264. It was then suggested on that ticket that Mutt could be changed to a 'vanilla' port which is plain upstream with no patches. I have attached a patch that does so, upgrades Mutt to the latest release version, 1.7.0 and enables the +ssl variant by default.

From what I could determine all previous patches on this port are either incorporated into NeoMutt or upstream Mutt, with the exception of ​https://dev.mutt.org/trac/ticket/3285. Since this patch is 7 years old and it was not adopted by either Mutt or NeoMutt, I assume that there isn't much demand for that change.

In case the idea of a 'vanilla' Mutt is accepted, I volunteer to be the maintainer with this port alongside the neomutt port — but with the understanding that to keep both ports easy to maintain I will try to maintain them free of local patches and steer any patch submissions to the NeoMutt project instead, which can keep them up to date.

[lbschenkel (Leonardo Brondani Schenkel)]

Remove all patches and upgrade to 1.7

[raimue (Rainer Müller)]

There is still one problem with this port: libraries will be picked up opportunistically if the corresponding port is already installed. This would lead to linking with a library from a port without recording the dependency in the registry. This problem existed before, but as you will take up maintainership I might as well mention it now. This can be fixed by using the following template for all variants:

configure.args    ... \
                  --without-idn \
                  ...

variant idn {
    configure.args-replace   --without-idn --with-idn=${prefix}
    depends_lib-append       port:libidn port:zlib
}

[lbschenkel (Leonardo Brondani Schenkel)]

You're right. I'll improve the patch and post here when I'm done.

[lbschenkel (Leonardo Brondani Schenkel)]

I'll fix neomutt as well, since I believe it has the same issue.

Note that it has been suggested on #52264 that neomutt could replace mutt because there may not be a lot of value in maintaining both ports when one is a superset of the other — personally I'm neutral about it.

[lbschenkel (Leonardo Brondani Schenkel)]

I fixed the opportunistic linking problem for the neomutt port and submitted it on #52291. I would appreciate if you could take a look there.

I just fixed neomutt and not mutt because in #52264 we are discussing the possibility of retiring the mutt port and I want to wait a bit to avoid wasting work. If you have any opinions on the matter, please let me know.

[lbschenkel (Leonardo Brondani Schenkel)]

I am going to obsolete mutt in favor of neomutt. Please close this ticket.

[lbschenkel (Leonardo Brondani Schenkel)]

I have proposed obsoleting the mutt port on #52297.

[neverpanic (Clemens Lang)]

Closing. If somebody has an interest in maintaining a vanilla mutt port, feel free to re-open or open a new ticket.

[vkuznet (Valentin Kuznetsov)]

I suggested on #52297 that it would be nice to have a mutt_select and still keep mutt and neomutt as separate port. The problem we users may face is that we don't know how our local configuration will work with neomutt and we need time to check that everything is ok and then make a final decision, e.g. to switch to neomutt. But it would be much easier to test options when we can select one or another product.

[neverpanic (Clemens Lang)]

Providing mutt_select would require making mutt and neomutt installable side-by-side, i.e. would require that none of their installed files conflict. I don't think that's a realistic goal for now, we should just declare neomutt and a potential vanilla mutt port to conflict, and users can activate and deactivate the ports as needed.

I've also mentioned in #52297 that you can re-activate the old mutt port if you're not ready to switch yet. If you see a use case for a mutt port that packages vanilla mutt, patches and maintainership would be welcome.

[lbschenkel (Leonardo Brondani Schenkel)]

Hi vkuznet, I have commented about your concerns in #52297.