Bug#727708: Init system resolution open questions
I think you and I have some fundamental disagreements about how this
decision-making process should work, so I'm not sure that we're going to
reach some satisfactory conclusion to this discussion. But I'll take
another try at this from another angle and see if it helps.
Adrian Bunk <bunk@stusta.de> writes:
> I think you missed my point.
> Assume a CTTE member wants that Debian does continue to have non-Linux
> ports, and therefore wants Debian to make the extra efforts for
> supporting a second init system besides systemd.
> What level of support (if any) would that guarantee for Debian's ports
> to non-Linux kernels?
I largely agree with Tollef's response. I don't think that viewing this
as a "guarantee" is a useful way of looking at the issue.
Let me provide a concrete example. Right now, we have a kFreeBSD port
that was, for wheezy, a technology preview, and for which we've generally
applied a release architecture attitude towards bugs. However, I maintain
a package that is simply not available on kFreeBSD (OpenAFS). It's not
been ported, I personally don't have the knowledge to figure out how to
turn the upstream FreeBSD kernel support into something that would work in
Debian, and if no one else steps forward to do the work, it's very likely
to continue to be unsupported.
This hasn't caused anyone any angst or excitement, despite the fact that,
in a concrete way, one of Debian's non-Linux ports is not as
well-supported as its Linux ports. There's a piece of software (one that
is quite important to some of our users) that is missing. And yet, the
port is still useful to the people who care about it.
Now, GNOME is obviously a much more significant and higher-profile piece
of software, and there's also a difference between something that has
never been supported and something that used to be supported but for which
upstream has dropped support. But the situations are more similar than
different, I think. See also the state of OpenJDK on kFreeBSD, which has
been tentative for a while, but which again does not destroy the value of
the port to the people who are using it.
The short version is that the level of support will be whatever people
have the time and inclination to achieve.
Now, what I hear you saying is, roughly, that you don't think that level
of support is worth the amount of work that would be required to maintain
parallel init systems, switching between init systems, and so forth, and
that either we should require a higher level of support than that, or we
should drop the whole concept of supporting multiple init systems.
You may be right that the level of effort is not worth it, which is one of
the reasons why I'm hestitant to lay out a bunch of requirements in
advance for Debian contributors to do a lot of work. However, I think we
disagree about whether we should decide this tradeoff in advance.
I also think you're overstating the amount of effort involved for the
typical package. This is exactly why I didn't trust my intuition and
actually went and did the work for one of my packages. I found that it
really wasn't that much work to support multiple init systems, and it's
work that mostly only has to be done once, and it's work that someone else
can easily contribute and the maintainer can just incorporate.
Yes, it's a lot of work for the init systems themselves, and for some
packages with complex setup requirements, particularly to support
switching, but that's also easier to test and to develop, because someone
who cares about the problem can join that maintenance team and extensively
test that one package. The work is isolated and easier to focus on. Or
those packages can be dropped on the port, depending on how important they
seem.
Also, just to expand on my previous example with another package: I am
upstream for a different package (lbcd, as it turns out, which I also used
as a test package for this discussion) that didn't have support for some
of its kernel operations on FreeBSD. It therefore failed to build on
kFreeBSD, and life went on. However, the lack of builds on all of
Debian's platforms bothered me at an aesthetic level, even though no one
ever asked for the package on kFreeBSD and so far as I could tell no one
cared. So, late last year, I took a few hours, did a bit of research,
discovered that porting the package to kFreeBSD under a set of assumptions
that are probably true of all Debian kFreeBSD systems wasn't actually
hard, and ported it. It's unlikely that anyone is going to care, but it
made me feel good to do it, and it wasn't that much effort.
This is exactly the sort of thing that Debian makes possible, and is
exactly the sort of thing that I don't want to *rule out* proactively in a
decision. I think it would have been ridiculous to *force* me to port
lbcd to kFreeBSD in some way (such as making it a requirement for lbcd to
be in the archive). But if the facilities are available (I used the
porter system to test, for instance), some people will just spontaneously
help because they want to.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: