Quoting Josh Triplett (2014-10-25 11:52:28) > [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 <ansgar@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). I meant examples not only of arch-constraints, but of arch-constraints being an *issue*. Seems you provide only the former above. Existence of arch-constraints is analogous to existence of init systems with different ABI. What we are talking about here is issues it causes - whether those are mostly theoretical or actually occuring in Debian, and whether they are treated as problems for package maintainers to deal with (Policy "forcing maintainers to do "extra work" as some put it) or not. > 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. Phrasing it as "have been willing" make it sound like optional work. Sure, in the end *all* work on Debian is volunteer, so even a "must" in Policy is something "packages have been willing to [...] support". >>> 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". A "should" regarding covering all, not describing coverage of some. > We've already had TC decisions that explicitly gave the equivalent of > a "should"; That was my impression too, when I read the announcement from the TC. It is *not* my impression that it has since been treated as 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. A "must" regarding "more than one", not describing coverage of all. No, it is equivalent of supporting _more_than_one_ architecture - where an equivalent of "do uselessd count?" would be "do X32 count?". > 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. I would actually favor such proposal over the current GR, exactly because to me this is *not* about covering *all* or sysV init specifically, it is about preserving choice - and for some weird reason it seems this GR is being misinterpreted as being damaging rather than ensuring a common sense and an existing practice (note "a" not "the"). >> 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. This GR is not about the virtues or not of some soecific init system - the analogy of that would be to discuss *which* architecture is better. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature