Bug#727708: init system discussion status
Dimitri John Ledkov <xnox@debian.org> writes:
> On 5 January 2014 01:26, Russ Allbery <rra@debian.org> wrote:
>> I'm amused by this comment given that one of the points of criticism of
>> systemd prior to this (by people other than yourself, to be clear) was
>> that the systemd maintainers were unwilling to apply and carry
>> necessary modifications and patch the source as necessary.
> Oh, that's interesting. I guess I have misunderstood your opinion email
> where you hail systemd as grand unifying interface. I shall re-read your
> that email, in light of all follow ups.
If you think that I said systemd is a grand unifying interface, you should
definitely re-read my email.
>> It seems like the systemd maintainers are going to get criticized by
>> someone no matter what course of action they take.
>> It's also worth noting that upstart in both Ubuntu and Debian carries
>> non-upstream patches or cherry-picks, for entirely reasonable reasons.
>> This is just something that's likely to be necessary with this sort of
>> package.
> Sure, the scope and size of the two, is however, greatly different.
My position on this is that both the upstart maintenance team in Debian
and the systemd maintenance team in Debian are competent, respected,
capable Debian developers, and I trust them to know how to maintain their
packages.
The pace of systemd development compared to the pace of upstart
development is certainly something to weigh as part of the overall
decision. Different people can arrive at different conclusions about
that, and I definitely respect the opinion that it's moving too fast and
is not stable enough to adopt, although I don't share it. But when it
comes to the exact details of how the maintainers are going to handle
patches and bug fixes and a release process, I see no reason not to trust
the maintainers of both packages to do their jobs.
>> Patching upstream unit files to change paths is trivial, but even
>> better would be to convince upstream to substitute in the proper path
>> when building the unit file. See the lbcd source package for an
>> example of how to do this properly. As a bonus, this means that the
>> unit files will also work if the upstream package is installed from
>> source using ./configure, make, and make install.
> Oh that indeed would be wonderful, why did systemd upstream advocate
> for hardcoded paths in so many projects then, instead of atleast
> runtime detected?! How is this suppose to work with 3rd party
> recompiled packages and e.g. installed in opt?
The approach used in the lbcd package should work with cases like that. I
welcome feedback on any issues I might have missed.
> previously just adding opt to PATH, or droppings things into
> /usr/local/, enabled to use custom compiled ad-hoc replacements as
> desired by deployments.
Not with init scripts in Debian it doesn't. Go look at the existing init
scripts and count how many use relative paths for their daemons and don't
reset PATH at the start of the script. I'm not just making this up.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: