But these are hard deps not just recommends so will pull in systemd dependencies regardless of it using them or not. If it were a recomends type dep, again no one would have a problem. It used to be considered bad packaging to hard dep when recommends or suggests would suffice.
7.2 states: "When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency"
You say "being able to use software under another init system." Looks like the level of dependency should be adjusted to fit your point.
You might want to learn how shared libraries work under Linux. Then you might be able to understand why packages have a Depends: libsystemd0 (which btw. doesn't depend on systemd itself).
They were told to by debian. They argued for as long as they could while debian was still 'their' distribution to change the direction systemd would take it. It was clean that wasn't going to happen. Final response; "If you don't like it you can always fork. But you'll never release anything."
So now they have forked and they have released. So now their splitters. Cake and eat it types, what can you do?
I don't follow. Are you saying that representatives of the Debian project refused to collaborate with the Devuan developers with regards to improving init system interoperability?
Where does that support the claim that
Debian would oppose people working on
sysvinit support?
In the body of the other[2] email where 'Option 2 "Support for other init systems is recommended, but not mandatory"' was selected by the Debian community. Once this path was chosen, while it theoretically isn't opposition, in practice it was only a matter of time before non-systemd init systems would become increasingly difficult to use in a systemd-leaning distribution (sysvinit or otherwise).
As Manfred Eigen said:
In theory, there is no difference
between theory and practice. But,
in practice, there is.
For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian. That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.
My point is more that systemd makes less sense if you think of it as just init. "Why does init need to manage -foo-?" is a valid question. But "Why does a general 'system daemon' need to manage -foo-?" tends to be self-answering.
Last i looked no-one wanted to maintain the shim, upstream looked dead, but things may have changed.