Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steven Chamberlain <firstname.lastname@example.org> writes:
> But that seems like the easiest way to not break what is already working
> in GNU/kFreeBSD, Hurd - and on users' own Linux systems if they have
> non-Debian software using SysV init scripts.
The last is unrelated. Both systemd and upstart support SysV init scripts
However, I, as a packager, want to stop writing and maintaining SysV init
scripts because they're awful. One of the huge benefits of adopting a new
init system would be the ability to replace 100+ lines of buggy and tricky
shell code with <20 lines of straightforward, descriptive configuration,
which would be the case for many of the init scripts in Debian.
> Dismissing the ports as toy projects is not a compelling argument to me.
I intensely dislike that phrasing and don't use it.
However, making all package maintainers continue to go through the pain of
maintaining SysV init scripts to support Hurd and kFreeBSD doesn't strike
me as a good outcome. One, I very much doubt that would actually happen
if such scripts were not required to make Debian on the major platforms
like amd64 and arm work properly. And, two, making packaging harder
because of missing capabilities inside Debian is just fundamentally not
how we should be attempting to operate as a project. We should instead
aim to bring the best technology to bear on the problem and move ahead as
> Just wondering, if systemd upstream cares only for Linux and that's
> considered okay, might they also start dropping support for
> architectures they stop caring about (or for commercial reasons)? Say
> MIPS, s390, SPARC. In that case, permanently ditching SysV init could
> put even some Linux ports in jeopardy. Perhaps Upstart carries the same
> risk if Ubuntu releases only for i386/amd64/arm.
Most upstreams in Debian only care about and only test on amd64 and i386.
This is a problem that we've dealt with for years by porting, providing
patches, and encouraging maintainers to fix issues in the name of better
portability. This by and large works provided that those architectures
can meet upstream halfway.
Where the architectures have not met upstream halfway by chronic lack of
such key components as effective threading systems or toolchain support,
we have dropped those architectures in the past. See, for example, hppa
I expect that pattern to continue: we will try our best to port Debian as
broadly as possible, and we will occasionally give up on a porting target
(at least outside of the secondary debian-ports infrastructure) because
there's too much work to do and insufficient resources.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>