Pierre Ynard <linkfa...@yahoo.fr> 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
