For better or worse I'm a heavy email user, not least because so much of the traditional workflows in Debian are email based. I use a variety of email clients but my swiss-army knife is mutt, and has been since at least 2005, which is the earliest-dated comment in my mutt configuration files.

I've always used the mutt package as provided by Debian, which means in practice I have been actually been using neomutt since around 2016, when the Debian maintainers imported that patch-set into the mutt package. neomutt is an independent effort to coordinate development of mutt (or on top of mutt) as the upstream maintainer(s) were (for a time) largely dormant. It's meant to be a friendly project, in some cases incubating patches that people are still trying to submit to the upstream project.

Fast forward to 2017 and an upstream mutt maintainer complained that Debian is providing something called "mutt" that is actually "neomutt" and started making pseudo-legal threats. This could have been resolved in a number of ways (my proposal and plea are recorded in that bug), but the decision of the package maintainers was to switch the mutt package back to the mutt source and provide neomutt as a separate Debian package.

We now have a situation where

  • If you were using mutt in Debian from 2016 onwards, you were most likely using neomutt, and your configuration files are most likely tailored to neomutt. If/When you upgrade to the next stable Debian release, you will be moved to real-mutt and your configuration may break.

  • if you filed a bug against the mutt package, depending when you did and what version of Debian you were using, your bug might be assigned to the mutt source package, which is now real-mutt, but might actually relevant only to neomutt. Looking merely at the list of bugs against "mutt" is not enough to be sure it's a bug in mutt, or neomutt, or both.

  • real-mutt and neomutt have not yet co-existed in a Debian release, so you cannot evaluate both side-by-side without introducing packages from testing or unstable, which might mean a libc upgrade.

  • Lots of stuff, especially Debian devscripts, hard-code /usr/bin/mutt as a mailer. The neomutt package does not provide this binary, and it is not mediated by the alternatives system, so if you only install neomutt, you might have integration niggles to solve yourself.

For a short while, I attempted to adjust my configuration files so that they would work in both real-mutt and neomutt, but this proved too messy so I've given up. I did have them co-installed on my main mail-reading host, but I also found myself occasionally confused as to which I was actually running at a given moment, so I've decided to stick to neomutt everywhere going forward: which means neomutt on my main mail host, and the mutt package on my Debian-stable hosts, and I must remember to switch the packages over when I update them to Buster (the next stable release) in a month or two.

The other upshot of this is I've decided to declare "year zero" on my mutt configuration files, rather than try to adapt the mess of mixed mutt and neomutt configuration bits spread across a dozen files that have grown since (at least) 2005, I'm going to start from scratch and only import over something if I feel its absence in daily use.


comment 1
Why don't they just drop normal mutt, use neomutt exclusively and have neomutt work like vim where it aliases to mutt? Also you can create a sudo package for mutt that just pushes the neomutt package. This way if you search for and install mutt you get neomutt, but all the branding is correct and users don't have to deal with confusion and devs don't have to track two packages? I'm no legal expert, but if that can get around the legal issues then that might be a nice work around.
Comment by Joe,
comment 1

Thanks for your post, and (now that I read the bug horror) thanks for your work on dealing with that #'&$'#&$'&$# upstream of mutt.

I am a mutt user since ~~ aehmm ~~~ before the turn of the century, cannot really remember. And I am facing the same problems on several of my servers now (mutt vs neomutt configuration).

I would have liked to see a different reaction of the maintainer - namely "Well, if you are so angry, go away, and we will only ship neomutt! Hope your project will perish!" but that didn't happen, and now we have the conundrum of (neo)mutt packages without alternative system.

This is something that puzzles me BTW, why not allow neomutt to provide mutt binary via alternatives?

Anyway, long live mutt! (Tried claws, alpine, thunder, even evolution - one always returns to *mutt)

Comment by Norbert Preining,