#52264 closed submission (fixed)
neomutt @20160910 New port as an alternative to mutt
Reported by: | lbschenkel (Leonardo Brondani Schenkel) | Owned by: | danielluke (Daniel J. Luke) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | Cc: | ||
Port: | neomutt |
Description
Neomutt is the latest release of Mutt (currently 1.7) with a collection of popular patches applied.
This port should be much easier to maintain than the existing mutt
port since some of the patches in that port conflict with each other (so they can't be enabled at the same time) and are version-specific (so they need to be refreshed on upgrades). None of these problems exist with Neomutt because they are resolved by the project.
I preserved all variants and defaults of the mutt
port, with the exception that I decided to enable ssl
by default.
I volunteer to maintain this port in case nobody else wants to be the maintainer.
Attachments (1)
Change History (11)
Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
comment:1 Changed 8 years ago by danielluke (Daniel J. Luke)
Owner: | changed from macports-tickets@… to dluke@… |
---|---|
Status: | new → assigned |
comment:2 Changed 8 years ago by danielluke (Daniel J. Luke)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
I think it makes perfect sense and it is a great idea. Actually what led me to introduce this port was that I was going to upgrade mutt to 1.7 but the patches broke and I was trying to find new versions of them, and I found neomutt in the process.
If we go forward with the idea of mutt being pure vanilla upstream, I volunteer to be the maintainer since I'm maintaining neomutt anyway. I can bump it to 1.7, drop all patches and put a note warning that to get the patches you should install neomutt instead.
comment:4 Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
I submitted an updated vanilla mutt port on #52267.
comment:5 Changed 8 years ago by neverpanic (Clemens Lang)
TBH I think we should just make the mutt
port ship neomutt and deprecate the mutt-devel
port in favor of a current neomutt. I don't think it's worth the effort to maintain an addition mutt port.
comment:6 follow-up: 7 Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
I don't object to this plan (and it's also less work for me). I just thought that some people may want to use 'vanilla' mutt.
comment:7 Changed 8 years ago by danielluke (Daniel J. Luke)
Replying to leonardo.schenkel@…:
I don't object to this plan (and it's also less work for me). I just thought that some people may want to use 'vanilla' mutt.
Since you're volunteering to be maintainer, you can decide which option you want to pursue (I think either is reasonable).
comment:8 Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
From a strictly maintainer perspective, naturally I would prefer to maintain just a single port instead of two. I see little reason for both to exist since neomutt
is a strict superset of mutt
— and in distros such as Debian the 'regular' mutt
package is also heavily patched as well (and some of these patches were taken from NeoMutt).
In case we go ahead with this plan, is there a way we could make one port an alias for the other? I try searching but I couldn't figure out how to do that. Should mutt
be an alias to neomutt
or vice-versa? What are your thoughts?
comment:9 Changed 8 years ago by neverpanic (Clemens Lang)
Look at the mutt-devel
Portfile, which is replaced_by mutt
. The same approach can be used to automatically replace installations of mutt
with neomutt
.
comment:10 Changed 8 years ago by lbschenkel (Leonardo Brondani Schenkel)
I have proposed obsoleting the mutt
port on #52297.
Minor changes to portfile + add conflicts to mutt portfile (r152763)
Thanks!
I would suggest it might be worthwhile to make the 'mutt' port only 'vanilla' mutt and let people who want the patched-in features use neomutt instead (mutt is currently nomaintainer, though, so someone would need to volunteer to maintain it - which I think would be more likely to happen if the maintainer didn't have to do as much patch juggling).