Norman Ramsey <n...@cs.tufts.edu> wrote: |> Norman Ramsey <n...@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.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
