Re: Tentative summary of the amendments
[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).
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
Reply to: