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 <b...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
