Bug#727708: init system discussion status
On 5 January 2014 01:26, Russ Allbery <rra@debian.org> wrote:
> Dimitri John Ledkov <xnox@debian.org> writes:
>
>> This confirms that systemd is not generic across all upstreams and all
>> distributions, and everyone is maintaining their own (in part influenced
>> by release cadence, and well distro-specific integration) Having git
>> repos, or even distro specific branches on Freedesktop.org would
>> help. Since well, it's suppose to be a cross distro collaboration
>> projects. I see little point in each distribution redoing it's own
>> stable maintainance.
>
> 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.
> 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.
>> A lot of debian-specific patches would be gone, if systemd did look up
>> daemons based on path instead of hardcoded paths, but alas that has been
>> rejected upstream.
>
> Because it's a horrible idea that Debian has already rejected for init
> scripts (see /etc/init.d/skeleton), and that we certainly shouldn't
> introduce when switching to a new init system.
>
> 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? previously just adding
opt to PATH, or droppings things into /usr/local/, enabled to use
custom compiled ad-hoc replacements as desired by deployments.
--
Regards,
Dimitri.
Reply to: