[Please CC me on replies; I'm not subscribed to -vote, so for mails not CCed to me, I end up responding via the archives and manually quoting via copy/paste.]
Jonas Smedegaard wrote: > Quoting Josh Triplett (2014-10-24 16:27:27) > > Aigars Mahinovs wrote: > >> On 24 October 2014 13:33, Ansgar Burchardt <ans...@debian.org> wrote: > >>> I don't like some software too, but am sometimes required to use it > >>> without an alternative. Can I demand that I can use packages without > >>> said software? Like demanding libraries having to provide language > >>> bindings for at least two languages so I don't have to use PHP[1]? > >>> :) > >> Init system is special because there can be only one active in the > >> system. If app1 depends on systemd (as PID 1) and app2 depends on > >> runit (as PID 1) then it becomes impossible to use both apps (without > >> changing init system and rebooting). Also IMHO init system should be > >> a user choice and not dictated by other, unrelated, software. > > > > Kernels are special because there can be only one active in the > > system. If app1 depends on Linux and app2 depends on FreeBSD, then it > > becomes impossible to use both apps (without changing kernels and > > rebooting). > > Can you provide any concrete examples of that actually being an issue? Yes, in both directions. For the more common "depends on Linux" case: portions of FUSE (partially addressed by a FUSE port for BSD, but not all filesystems work with that), ALSA (and indirectly anything using it for sound), BlueZ (Bluetooth support), more recent inotify-like interfaces, many networking and wireless tools, cell modem support, many filesystem tools, various hardware access libraries, some backup tools, some build tools, systemd and systemd-shim, and until not too long ago sysvinit. (That's only the software that *explicitly* only runs on Linux, as opposed to software which says "any" but doesn't build or run on FreeBSD, which I'd assume applies to a non-zero number of packages.) For the fairly rare (at least in Debian) "depends on FreeBSD" case, I only know one example off the top of my head: ZFS (since Linux only has the low-performance zfs-fuse). So, in a situation rather analogous to the init systems: Linux runs just about everything, FreeBSD runs most things but has little that specifically depends on it. Which makes this a fairly small problem for Linux users, and a noticeable lack if you want to run FreeBSD. However, the FreeBSD folks have done an impressive job keeping up, and many packages have been willing to add FreeBSD support. (Processor architectures have a similar situation, most notably with packages that generate code and the packages that build-depend on those.) > Reason for this GR is concrete examples (thankfully believed solved by > now) of it actually being an issue regarding init systems. I have no reason to believe that the situation with init systems is drastically different than those for kernels or for architectures. In both cases, I think the right answer is for package maintainers to declare appropriate dependencies to reflect reality, for upstreams to consider carefully the tradeoffs of portability, and for port / init system supporters to continue writing and submitting patches or developing alternatives. Neither case justifies a GR or a policy "must". > > And yet we don't stop applications from declaring "Architecture: > > linux-any". And the world has not ended. People who maintain > > non-Linux kernels have a substantial amount of work to do, and I find > > it very impressive how much they've gotten working. Yet nobody has > > proposed a GR forcing support for kFreeBSD or the Hurd; the people > > working on them have simply *done the work*, and in some cases > > successfully convinced others to do the same. > > We do strongly discourage that, as codified in Debian Policy ยง5.6.8: > > > Specifying a list of architectures or architecture wildcards other > > than `any' is for the minority of cases where a program is not > > portable or is not useful on some architectures. Where possible, the > > program should be made portable instead. > > Notice the "should" near the end of above. Notice as well that it doesn't say "must". We've already had TC decisions that explicitly gave the equivalent of a "should"; this GR would effectively enforce a "must", making it RC to depend on an init system. The equivalent would be making it RC to not support all architectures. And while portability can potentially be a desirable feature, that doesn't make it RC to build architecture-specific software. If the GR had language like this: "Depending on one or more specific init systems is for cases where a program is not portable across all init systems or not useful under other init systems. Where possible, the program should be made portable instead." then I wouldn't be arguing against it, other than that a GR would be overkill compared to proposing that via the Policy process instead. > Do you consider init 1 more similar to kernel or more similar to PHP? For the purposes of this particular analogy, the former. (I'll refrain from jokes at PHP's expense here. :) ) Incidentally, to further extend the analogy: to me, many of the calls to stop implementing features and interfaces in systemd and implement them outside of systemd instead come across in much the same way as calls to stop implementing features and interfaces in the Linux kernel. We don't make a habit of systematically implementing all functionality outside the kernel on production systems just so we can swap out the kernel on a whim. Some things simply make more sense in the kernel. And the interfaces implemented so far require at least as much integration with systemd functionality as, say, PCI device drivers require with the Linux kernel. Sure, you *can* implement a PCI device driver in Linux userspace, but doing so has numerous problems, and few systems use that in production. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141025095227.GA2566@thin
