[ please keep me in CC, I'm not subscribed to this list]
Sam Hartman wrote:
> My understanding is that systemd's implementation of tmpfiles and
> sysusers works even while systemd is not pid 1.
> Why do we need multiple implementations for Debian ports where systemd
> runs?
> I understand why we might want alternatives for kfreebsd and hurd.
> But if my understanding that the systemd implementation does not require
> systemd be running as pid 1, why do we need alternatives for the glibc
> linux ports?
Why dump additional work on non-linux porters when we ( alternatives
inits supporters)
can have one implementation that works on both linux and non-linux?
Please consider that beeing able to work on non-linux port it's a
feature that many
(if not all) alternative inits provide while systemd doesn't.
That feature it's clearly not important for a systemd advocate,
but may be important for a sysv/openrc/runit user/contributor.
In wich way having an alternative implementation of tmpfiles.d
and sysuser.d around will harm systemd?
I read your proposal B several times:
'Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features. Those interested in exploring such alternatives need to
provide the necessary development and packaging resources to do that
work.'
What do you mean exactly with "alternatives to features"?
Please clarify, because here I see two alternatives to features and at
least one person
that is offering to do the job.
But there is more:
let's take tmpfiles.d: I don't like how systemd handles
tmpfiles creation and I do consider it totally unfitted
for my favourite init (runit).
* Why do I need to create all directories and files for all
installed services at boot?
* Why do I have to create directories and files in maintainer
scripts?
* Since I have a central utility that creates directory and files
(which you guess what... i don't like it LOL, because it's a utility
that can fail all your services at once if something goes wrong)
why not let such utility create all directories needed by a service?
I just need an utility like the following:
'mksvdir foo' --> create all (not just temporary) dir and files for foo service
'mksvdir delete foo' --> delete temporary dir and files for foo
then call such utility in invoke-run intepreter, and fail the service if
it exits non-zero. that's it.
Since invoke-run is executed only if runit is installed I can even
make 'mksvdir' a dependency of runit without bothering foo maintainer
with another dependency that almost nobody uses.
Is systemd upstream or debian maintainers available to accept patches that
adapt it's facilities to the needs of other inits?
IMHO imposing a systemd facility when there are alternatives and people
available to do the work it's a perfect setup for keep on arguing and fighting
Regards,
Lorenzo
