Bug#885537: nullmailer: Please restore sysvinit support

[David Bremner]

Pierre Ynard  writes:

> As mentioned in the changelog and discussed in #884980, support for sysvinit
> was dropped. 

First, thanks for the bug report. I think it will be useful to have a
central place to discuss this. With that in mind, if it was simple to
support sysvinit in the new version, I would have done so; consequently
I personally don't forsee working on this.

> Please keep packaging a version that supports sysvinit. Please keep
> supporting the necessary patch against new upstream versions,

I don't have time/motivation to maintain such a patch. If someone else
does, I think it should best be done upstream. It might be that
something less intrusive than the previous patch would be acceptable to
upstream; I seem to recall the previous patch was rejected there.

> or rework the initscript if possible.

I don't know what specifically would be involved with that. If someone
has concrete suggestions for initscripts that work acceptably with the
current version nullmailer, then I encourage them to submit them to this
bug. It's presumable better to first determine what features are needed
for such an an init script, before thinking about a patch.

> Alternatively, please keep maintaining and packaging version 1.13 that
> includes the necessary patch.

Again, that's not a task I'm interested in taking on. Nothing stops
someone else from maintaining a "nullmailer-legacy" package (supposing
the security team can live with the idea).

> As mentioned in #884980, please document alternatives to nullmailer,
> so users like me can choose between holding the outdated package or
> uninstalling nullmailer.

I don't have any personal experience with alternatives to
nullmailer. "apt search mail-transport-agent" suggests dma, esmtp-run,
msmtp-dma, proxsmtp, and ssmtp. I suspect that such a survey would get
out of date quickly, and is most suitable for a wiki page than package
documentation, but I guess if someone wants to curate a list, I can
include it.

> Alternatively, please provide a way for users to install the software
> without the mandatory switching to systemd init, and let them tinker
> with their own startup solution, perhaps shipping the old initscript in
> /usr/share/doc/ as a basis.

I'm open to ideas for how that can done in a way that install is
actually functional (i.e. that don't re-open #884980).



signature.asc
Description: PGP signature

Bug#885537: nullmailer: Please restore sysvinit support

[Pierre Ynard]

Package: nullmailer
Version: 1:2.1-5
Severity: wishlist

Dear Maintainer,

As mentioned in the changelog and discussed in #884980, support for sysvinit
was dropped. For reference, quoting relevant entries:

 - changelog.Debian

> * Drop support for sysvinit, due to dropping --daemon divergence from
>   upstream

 - NEWS.Debian

> * Support for sysvinit is not available in this version.  This support
>   relied on a patch against upstream which is no longer being carried in
>   Debian.

 - README.Debian, possibly related

> On request of its users the Debian version of nullmailer-send behaves
> differently from the corresponding upstream release. It forks into the
> background on startup and it sends status output to the system log
> daemon instead to standard error. If you have no running system log
> daemon, output will be sent to /dev/console. As of 1.00RC7-12 this
> behavior is optional and needs to be requested using nullmailer-send's
> --daemon and --syslog options (Debian only), see nullmailer-send(8).

As a result, we have a package that is a really simple and small MTA,
but mandates a given init system. I would even say that considering
nullmailer's purpose is to provide a simple and lightweight alternative
solution to uselessly constraining full-featured MTAs, this comes across
as self-defeating and at odds with your target users.

This moves leaves me shocked and perplexed. I read and understand the
logic behind the systemd-sysv dependency, but the situation seems really
wrong to me.

Please keep packaging a version that supports sysvinit. Please keep
supporting the necessary patch against new upstream versions, or rework
the initscript if possible.

Alternatively, please keep maintaining and packaging version 1.13 that
includes the necessary patch. Personally speaking, there is no way I'm
switching to systemd for nullmailer, so there is no way I'm upgrading
from my working 1.13 version to version 2 with the current dependency.
As mentioned in #884980, please document alternatives to nullmailer,
so users like me can choose between holding the outdated package or
uninstalling nullmailer.

Alternatively, please provide a way for users to install the software
without the mandatory switching to systemd init, and let them tinker
with their own startup solution, perhaps shipping the old initscript in
/usr/share/doc/ as a basis.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages nullmailer depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  init-system-helpers1.51
ii  libc6  2.25-5
ii  libgnutls303.5.16-1
ii  libstdc++6 7.2.0-18
ii  lsb-base   9.20170808

Versions of packages nullmailer recommends:
ii  rsyslog [system-log-daemon]  8.31.0-2

nullmailer suggests no packages.

-- debconf information excluded