On 17/06/15 11:09, Roger Leigh wrote:
On 16/06/2015 19:47, Anto wrote:
Thanks a lot Roger for your explanation.
However, I still fail understand how to implement what you explained
without changing anything on any other packages that have daemons to be
managed by epoch. As I mentioned on one of my emails on this thread, the
implementation has always been to include the files specific to the init
systems into those packages. I still can not believe that this is the
only way. Could we not have some kind of man-in-the-middle (I believe
the programming term is API) to be used by all packages including the
init systems that are totally independent, to talk to each other? I am
sorry for those silly questions, but it would be great if you could
explains the reasons why the implementation is always like that and the
impacts if we would divert from that.
I think for me that would also explain why there is no other way to
avoid lock-in to systemd rather than forking Debian.
Historically, every new init system (or at least, new in Debian) has
strived for some degree of compatibility with sysvinit. Both upstart
and systemd will run traditional init.d scripts, and both plug into
update-rc.d to act on changes. Had we been able to go forward with
openrc support, we would have done the same there as well (I think
patches were made for this already). upstart didn't make use of the
LSB dependencies; systemd does to an extent but in practice it doesn't
work as well as it could.
In short, if epoch can't make use of the existing init scripts
provided by all packages, it's going to have a very big struggle. It
absolutely must be a drop-in replacement for the existing system in
order to be viable. There's over two decades of accumulated knowledge
in the existing scripts (not for all daemons, but particularly
initscripts and other core scripts). Witness the large number of
regressions and now unsupported configurations with the systemd
switch--this is largely due to dropping all that without
reimplementing it properly. Now systemd will use its own
configuration files preferentially, and use the init scripts where
necessary, so from its POV it's a relatively smooth transition where
individual packages can add systemd units relatively easily. epoch
much consider doing something similar, since having flag day where
every package adopts a brand new format is simply logistically
impractical.
Regards,
Roger
Hello Roger,
Thanks a lot again for your explanations and suggestions.
From what understood so far about epoch init system (very thin as I
just started a few days ago), it is not meant for Linux only. So I got
the impression that epoch package should be independent to what ever
rules a distro currently use. But as you explained, it will be quite
hard to achieve that independence on a mature distro like Debian. So I
guess that would only be achievable on totally new distro. Hmmm...
perhaps this is an idea a new distro. :)
Cheers,
Anto
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
