That depends. The reason I skipped some of the patches is because I think they were changes that would degrade sysvinit's functionality and performance by adding dependencies on and calls to systemd that would not be needed when running with sysvinit. Debian should have forked the package and kept a pure sysvinit package, and a clean systemd version using provides to resolve the dependency tree issues.

I think the best way forward would be to pull the whole git repo from debian for this package as then we can easily revert all the systemd related patches. This would allow us to rebase of the debian package to keep track of changes that will effect other packages whilst allowing us to keep it clean of systemd. (The reverts will be fast-forwarded on a rebase so we will only need to add new reversions for new commits containing systemd cruft).

With regards to init freedom, systemd itself prevents that so I don't see it as a valid argument to keep huge amounts of systemd cruft. Those that want Devuan with systemd should be directed to Debian instead.

I'd be happy to work on this post release (unless it's needed earlier).

I think for jessie release it's ok this way, so, we are not in hurry about that.

As for tracking debian changes, this is one of the packages i don't really think we should follow debian. Instead, we should track upstream for sysvinit ( i/e http://download.savannah.gnu.org/releases/sysvinit/ ) and fork the debian directory completely, and then we should think about removing any systemd reference from the package as don't needed in devuan at all.

Status changed to closed

Status changed to reopened

I think that we should only fork and diverge from Debian or rebase on upstream when Debian makes fundamentally signifcant changes that require us to do so. We are not at that point yet with this package, and the effort required to keep this package free from systemd by my proposed approach is lower then the effort required to maintain it as an entirely separate package whilst keeping track of everything else. For every package we diverge from Debian we increase the number of dependencies and reverse-dependencies we also will need to touch.

This is likely to happen anyway, but we should take a conservative line on this and only fork what we have to in order to preserve init freedom.

@CenturionDan basically i agree with you, the difference is that i think that debian maintainance of the package will probably be systemd-focused, so, i really think that in (close) future maintain our own scripts for devuan will be a less effort compared to clean systemd focused scripts from the debian package...

Anyway, let us discuss this more deeply after devuan jessie release, for the moment is enough to fill up our repo with all needed branches to make it buildable on our jenkins infrastructure.

Also, we should ask rleight, as he was positive about devuan, if he want to maintain sysvinit in devuan too or we should take off maintainance

I think it's more likely based on the changes I've seen that debian is moving the functionality systemd needs out of this package, so that it doesn't need to rely on this package at all and will ultimately leave it to those wanting sysvinit to maintain.

I'm happy to either co-maintain or take over if he's lost interest.

We really need to get team email addresses/mailing lists to make it easier to coordinate without relying on issues or irc.

@CenturionDan i'll talk about that with @jaromil , he is the "postmaster" as he have the control of mailserver :)