>>>>> "Sam" == Sam Hartman <hartm...@debian.org> wrote:
>>>>> "Simon" == Simon Richter <s...@debian.org> writes:
>>>>> "Sam" == On 6/29/23 01:56, Sam Hartman wrote:
Sam> It also seems a bit strange to require more from the maintainer
Sam> when they are dropping an init script than we would if a
Sam> maintainer started depending on a feature like socket activation
Sam> such that their package simply would not work without systemd.
Simon> This would be a case where the init script and the systemd
Simon> unit deviate in functionality. I don’t see a problem with
Simon> that, and my expectation is generally that the people running
Simon> sysvinit and the people running systemd have different
Simon> expectations here anyway.
That’s my impression as well. Personally, I’m not going to
expect for daemons started via different init mechanisms to
behave identically, either.
Sam> It would be entirely permitted under GR 2019-002 for me to build
Sam> a version of krb5-kdc that was compiled to depend on socket
Sam> activation and would not work without systemd.
Sam> I would not be required to provide any transition when doing that.
Sam> (To be clear, I have no such plans, and in the case of krb5kdc
Sam> don’t currently think it would be a good idea).
I’m not sure it’s solely within the scope of the GR.
When doing development and testing, I’ve found it useful to be
able to start server processes from my own code. So, for example,
I’d have a wrapper that’d do initdb on a temporary directory,
start a PostgreSQL server process there, load the schema and
test data, run a test suite, kill the server and remove the
directory. No system-wide PostgreSQL instance is ever started
on that system, so the choice of the init system is hardly
relevant. (Never had a reason to start a KDC in such a way,
but I’m not going to swear no one will ever need it, either.)
I’d rather appreciate if this particular rug isn’t pulled from
under my feet at some future date.
Not that I’d expect it to be, mind. So far my experience with
Debian packages has been that they tend to come with as much
upstream features enabled as possible (to the point where I
sometimes wish it weren’t the case.)
If there’re concerns that a package maintainer might decide to
deviate from such a practice for ill reasons, I suppose it should
be codified within the policy. Otherwise, so long as as a
given daemon can be started via fork and exec, it can be started
from an init.d script just as well; while removing support for
such use might affect users beyond those who rely on init.d.
PS. The orphan-sysvinit-scripts package now has my attention.
--
FSF associate member #7257 np. A Gentle Place by Lisa Lynne
