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