Dear Maintainer,

I upgraded from jessie to stretch, and I expected to continue using
heirloom-mailx as my implementation of mailx.  But my system was
somehow switched to bsd-mailx.  Worse, update-alternatives is not
capable of changing back:

  nr@homedog ~/e/j/tufts> sudo update-alternatives --config mailx
  There are 2 choices for the alternative mailx (providing /usr/bin/mailx).

    Selection    Path                Priority   Status
  ------------------------------------------------------------
  * 0            /usr/bin/bsd-mailx   50        auto mode
    1            /usr/bin/bsd-mailx   50        manual mode
    2            /usr/bin/mh/mhmail   25        manual mode

I expected /usr/bin/heirloom-mailx to be an alternative on this menu.

This is possibly the same bug as 858080, but I don't know enough
Debian jargon to know for sure.


Norman Ramsey

Norman Ramsey <nr@cs.tufts.edu> wrote:
 |I upgraded from jessie to stretch, and I expected to continue using
 |heirloom-mailx as my implementation of mailx.  But my system was
 |somehow switched to bsd-mailx.  Worse, update-alternatives is not
 |capable of changing back:
 ...
 |I expected /usr/bin/heirloom-mailx to be an alternative on this menu.
 |
 |This is possibly the same bug as 858080, but I don't know enough
 |Debian jargon to know for sure.

The just released S-nail/mailx v14.9.0 adds support for custom
headers, so one could possibly hope something moves on.
That is all i (as the S-nail maintainer) can do,
Ciao!

 > Norman Ramsey <nr@cs.tufts.edu> wrote:
 >  |I upgraded from jessie to stretch, and I expected to continue using
 >  |heirloom-mailx as my implementation of mailx.  But my system was
 >  |somehow switched to bsd-mailx.  Worse, update-alternatives is not
 >  |capable of changing back:
 >  ...
 >  |I expected /usr/bin/heirloom-mailx to be an alternative on this menu.
 >  |
 >  |This is possibly the same bug as 858080, but I don't know enough
 >  |Debian jargon to know for sure.
 >
 > The just released S-nail/mailx v14.9.0 adds support for custom
 > headers, so one could possibly hope something moves on.
 > That is all i (as the S-nail maintainer) can do,

Sorry, I think I misunderstand something.  I would think that
participation in update-alternatives would be a packaging issue, not
an upstream issue.  And I don't see a connection to custom headers...



Norman

Norman Ramsey <nr@cs.tufts.edu> wrote:
 |> Norman Ramsey <nr@cs.tufts.edu> wrote:
 |>  ...
 |>|I expected /usr/bin/heirloom-mailx to be an alternative on this menu.
 |>|
 |>|This is possibly the same bug as 858080, but I don't know enough
 |>|Debian jargon to know for sure.
 |>
 |> The just released S-nail/mailx v14.9.0 adds support for custom
 |> headers, so one could possibly hope something moves on.
 |> That is all i (as the S-nail maintainer) can do,
 |
 |Sorry, I think I misunderstand something.  I would think that
 |participation in update-alternatives would be a packaging issue, not
 |an upstream issue.  And I don't see a connection to custom headers...

It was my understanding that we have been removed as an
alternative because we did not support custom headers: it seems
some scripts (a pretty bad shell script has been linked to in one
of those Debian issues), i think it had something to do with cron
.. anacron maybe it was?) relied on an -a command line option to
add custom headers.

This -a seems to be a Debian extension to BSD Mail that has been
introduced some months after nail->Heirloom mailx->S-nail
introduced -a for adding attachments, i.e., this usage has always
been broken, then.

And thus, because of this situation, i interpreted those reports
one of which you referred to as social pressure a.k.a. lobbyism to
get custom header support in the thing i maintain.  (Moreover,
a functioning predecessor was available at that time already, in
fact since January 2016, but i was not happy and the environment
as such was absolutely not right to make a release.  And of course
we do not offer -a, because that is taken for attachments, and
i think that makes more sense than -a meaning custom headers.)

 >  |Sorry, I think I misunderstand something.  I would think that
 >  |participation in update-alternatives would be a packaging issue, not
 >  |an upstream issue.  And I don't see a connection to custom headers...
 >
 > It was my understanding that we have been removed as an
 > alternative because we did not support custom headers...

That's appalling.

 > This -a seems to be a Debian extension to BSD Mail that has been
 > introduced some months after nail->Heirloom mailx->S-nail
 > introduced -a for adding attachments, i.e., this usage has always
 > been broken, then.

Oy.  I gather, then, that s-nail cannot be an alternative unless some
sort of political settlement is brokered, which may never happen.  Alas.

Well, thank you for explaining the situation so clearly.
It may amuse you to know that I first noticed the substitution
(bsd-mailx for heirloom-mailx) because my -a command lines were
not working as expected.  Sigh.

Good luck getting things sorted out with your colleagues.
Perhaps this bug report can serve as evidence that s-nail is an
important alternative for mailx, and that the inconsistencies should
be sorted out.  I have been using mailx -a at least since jessie and
maybe longer...


Norman

Norman Ramsey <nr@cs.tufts.edu> wrote:
 |>|Sorry, I think I misunderstand something.  I would think that
 |>|participation in update-alternatives would be a packaging issue, not
 |>|an upstream issue.  And I don't see a connection to custom headers...
 |>
 |> It was my understanding that we have been removed as an
 |> alternative because we did not support custom headers...
 |
 |That's appalling.

Well, maybe that word is a bit excessive for a non-critical
software package.

 |> This -a seems to be a Debian extension to BSD Mail that has been
 |> introduced some months after nail->Heirloom mailx->S-nail
 |> introduced -a for adding attachments, i.e., this usage has always
 |> been broken, then.
 |
 |Oy.  I gather, then, that s-nail cannot be an alternative unless some
 |sort of political settlement is brokered, which may never happen.  Alas.

That was my impression at least.  Of course this MUA is still very
restricted, so in parts i can even understand the trouble.  We are
getting better, but it takes quite a lot of time.

 |Well, thank you for explaining the situation so clearly.
 |It may amuse you to know that I first noticed the substitution
 |(bsd-mailx for heirloom-mailx) because my -a command lines were
 |not working as expected.  Sigh.
 |
 |Good luck getting things sorted out with your colleagues.
 |Perhaps this bug report can serve as evidence that s-nail is an
 |important alternative for mailx, and that the inconsistencies should
 |be sorted out.  I have been using mailx -a at least since jessie and
 |maybe longer...

Thank you.  That would be nice.  I hope the improvements will make
you like it better than ever before.
Ciao!

So what is the status of this bug?

heirloom-mailx is now a transitional package to s-nail, but s-nail does
not proved "mailx". At least on stretch (Deb9).

Not very transitional if the same commands are not provided.

...so why isn't heirlom-mailx not just added with a lower priority than
BSD mail? It would not disturb anyone and those who dislike mailx from
BSD mail or wherever could easily change it to heirlom-mailx. No one
ever said that an alternative must be switch compatible, I think. See
the Debian Wiki [1] where a discussion on debian-user is linked, which
talks about vim, nvi and elvis, which do not support the same key
strokes and are nevertheless alternatives.

Actually I could just state that I've used to use a dot to end the
interacive mail command since the very early nineties, which doesn't
work any more today. So what's that reasoning about a missing -a switch
compared? The same level of unimportance....

Please just add it as an alternative with lower priority. If anyone
feels distracted even by such a non-invasive method, (s)he could open a
bug, I suggest and the discussion could start over.

Regards, Adrian.


[1] https://wiki.debian.org/DebianAlternatives

As of trixie, heirloom-mailx is an alternative for mailx:


```
nr@homedog ~/n/s-nail-14.9.25> update-alternatives  --list mailx
/usr/bin/bsd-mailx
/usr/bin/heirloom-mailx
/usr/bin/mail.mailutils
/usr/bin/mh/mhmail
nr@homedog ~/n/s-nail-14.9.25> dpkg -s heirloom-mailx
Package: heirloom-mailx
Status: hold ok installed
Priority: optional
Section: mail
Installed-Size: 508
Maintainer: Hilko Bengen <bengen@debian.org>
Architecture: amd64
Version: 12.5-4
Replaces: nail
Provides: imap-client, mail-reader, mailx
Depends: base-files (>= 2.2.0), libc6 (>= 2.14), libgssapi-krb5-2 (>= 1.17), libssl1.1 (>= 1.1.0)
Suggests: exim4 | mail-transport-agent
Conflicts: mailutils (<< 1:1.1+dfsg1-4), mailx (<< 1:20071201)
Conffiles:
 /etc/nail.rc 0b38ebc4dc092bfe594c4b07f7df37d6
Description: feature-rich BSD mail(1)
 Workalike of the classical mail(1). Heirloom mailx can produce and
 read MIME and S/MIME messages and has greatly improved character-set
 handling, including support for UTF-8.
 .
 It can send messages through a local /usr/bin/sendmail interface or
 SMTP, using a smarthost. Mail can be read from local mailboxes as
 well as via POP3 or IMAP connections. Network protocols can be
 encrypted using SSL/TLS.
Homepage: http://heirloom.sourceforge.net/mailx.html
```


This bug can be closed.

Hi, the heirloom-mailx package has been removed in version 14.9.4-1. You
likely have an old version of the package installed. Relevant changelog
excerpt:

s-nail (14.9.4-1) unstable; urgency=medium

  * New upstream version 14.9.4
  * Modernize package: DH compat level, Vcs-* URL, Standards-Version
  * Remove heirloom-mailx transitional package (Closes: #876871)
  [...]

 > Hi, the heirloom-mailx package has been removed in version 14.9.4-1. You
 > likely have an old version of the package installed. Relevant changelog
 > excerpt:
 >
 > s-nail (14.9.4-1) unstable; urgency=medium
 >
 >   * New upstream version 14.9.4
 >   * Modernize package: DH compat level, Vcs-* URL, Standards-Version
 >   * Remove heirloom-mailx transitional package (Closes: #876871)
 >   [...]

Fair enough.  Is that a reason to leave #867623 listed as "outstanding"?
(The issue was resolved in heirloom-mailx 12.5-4, and my tidy mind
would prefer to see it closed.)


Norman

Control: severity -1 wishlist

---
s-nail (14.8.14-2) unstable; urgency=medium

  * Remove mailx alternative for s-nail / heirloom-mailx (Closes: #846062).
    The command line interface for mailx is not well-enough defined for
    Debian's alternatives system to be useful at all.
---

Indeed this bug was filed (by you, I now realize) against version
14.8.16-1, i.e. after 14.8.14-2.