The Debian init system general resolution returns
The Debian init system general resolution returns
Posted Oct 18, 2014 19:24 UTC (Sat) by Zack (guest, #37335)In reply to: The Debian init system general resolution returns by pizza
Parent article: The Debian init system general resolution returns
Why should I be doing unpaid work for an init system I do not want or need? It's great people like systemd and have a high opinion of it, but that opinion should really end when it's about to be installed on someone else's machine as a dependency.
Posted Oct 18, 2014 19:50 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (8 responses)
And as has been linked in this article's comments already, nothing that worked with sysvinit before doesn't work now. As such, I think Lucas' amendment makes much more sense than Ian's.
Posted Oct 20, 2014 4:24 UTC (Mon)
by edomaur (subscriber, #14520)
[Link] (5 responses)
Anyway, as a sysadmin with a bunch of servers on Debian and RedHat EL, and I am quite happy to get systemd on both : this way, I will (probably) not needing to write the same scripts 2 time each, and I will be able to remove some complexity from my day job.
Posted Oct 20, 2014 10:21 UTC (Mon)
by Zack (guest, #37335)
[Link] (4 responses)
This isn't about systemd's availability in Debian, it's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
Posted Oct 20, 2014 11:45 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (3 responses)
AFAIK there is no evidence that this is actually a problem. Please tell me about such a case if one exists.
I don't think package maintainers will deliberately refuse to merge contributions by interested third parties that enable their packages to run with particular init systems. It's just that package maintainers should not be forcibly volunteered by third parties to come up with the required code by themselves if they don't want to (which would be against Debian's constitution).
One solution could always be to team-maintain the packages in question such that maintainer A can take care of the adaptation to init system X that maintainer B (for whatever reason) doesn't want to touch, while maintainer B maintains the adaptation to init system Y that maintainer A (for whatever reason) doesn't want to touch. On the whole, Debian package maintainers are reasonable people, and it should generally be possible to work something out.
Posted Oct 20, 2014 13:27 UTC (Mon)
by Zack (guest, #37335)
[Link] (2 responses)
> I don't think package maintainers will deliberately refuse to merge contributions
And I'm not so sure about that. This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
This GR isn't about shoving around work; it's about reassuring those who are not (yet) convinced about systemd, that Debian is still a suitable distribution for them and that their contributions are welcome.
Posted Oct 20, 2014 15:31 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
I think that the GR is only peripherally connected with that. As I said, even without the GR it is unlikely that package maintainers will deliberately decline to include support for other init systems than systemd if that support is volunteered by interested third parties.
It seems to me, though, that the GR in its present form tries to force package maintainers to create support for additional init systems even if the upstream package doesn't come with such support and nobody else steps forward to do it. In addition, it is unclear whether packages must support all init systems that are part of Debian or whether any two will do as long as one of them is systemd. One might also ask exactly what actually constitutes an “init system”.
In my opinion it is unreasonable to ask package maintainers to actively create support in their packages for additional non-default init systems. As of now most if not all relevant packages do support sysvinit, and that support should not be removed without good cause. Bug reports can be opened if required, and if the package maintainers don't (or can't) take care of them themselves then those people who are sufficiently interested in keeping sysvinit support going in Debian can help out. The same goes for support for things like Upstart; I don't think package maintainers should be compelled to add, debug, and maintain Upstart support for packages that don't come with it in the first place. If they want to do it, fine; but let those people who are interested in widespread Upstart support in Debian do the work if the package maintainer won't or can't do it, and have the package maintainer integrate it once it is done.
Posted Oct 20, 2014 17:32 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link]
What this GR does is make specific set of potential release blockers... regardless of whether patches have been contributed or not.
And let me be clear about this... this GR is not scoped to be just about ensuring a systemd transition from sysvinit.
In the future, post jesse if uselessd shows up in the repo, and uselessd works as a systemd replacement that will meet the requirement of this GR, without anything having to continue to work with sysvinit.
And that is the fundamental problem with this GR. It's not actually addressing the specific ongoing concern of making sure users can transition from old default (sysvinit) to new default (systemd) with minimal disruption.
The abstract language of the GR about init choice is just silly. Nobody really expected everything to work with mini as an alternative init without a lot of close hand-to-hand combat by the admin. The "freedom" to choose an alternative init has been until this point in time the "freedom" to break your system by choosing to use an alternative init.
This GR tries to make an overly broad policy statement that drastically changes the character of how all alternative inits are to be handled, but does not actually do anything to address the ongoing concern of transitioning from an old default init to a new default init...which is the only actionable concern that was triggered by choosing to change the default init.
-jef
Posted Oct 20, 2014 21:29 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Actually, the LO devs (and I should know, I'm involved in it) ARE rewriting LO to remove the Java dependency. Incidentally, if you do build LO --without-java, pretty much the only thing that will break is Base.
Cheers,
Posted Oct 26, 2014 19:23 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 20, 2014 0:56 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
It's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.
The Debian init system general resolution returns
The Debian init system general resolution returns
This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.
The Debian init system general resolution returns
The Debian init system general resolution returns
Wol
The Debian init system general resolution returns
The Debian init system general resolution returns