Re: Tentative summary of the amendments
On Sat, Oct 25, 2014 at 03:21:51PM +0200, Jonas Smedegaard wrote:
> Quoting Josh Triplett (2014-10-25 11:52:28)
> > 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.
Any missing functionality or packages on kernel or architecture A
compared to B certainly is an issue for the people wanting to run A, and
presumably the users, developers, and maintainers of A would like to see
more packages and more functionality run on A. Policy certainly doesn't
force package maintainers to do extra work in this case, because it
places no hard requirements on architecture support. Porters write
patches, and as I understand it the FreeBSD architecture maintainers do
spend a significant amount of time making things work on FreeBSD and
removing Linux-specific assumptions from code. FreeBSD developers
upstream also work to provide kernel functionality to help support a
broader range of software (e.g. linprocfs).
Beyond that, I don't see what distinction you're drawing by about this
being or not being an "issue". As mentioned below, the world certainly
hasn't ended over it. Likewise, I don't know of any current "issues"
caused by init-system-specific software that haven't already been fixed,
and the world hasn't ended over that either.
For architectures, kernels, *and* init systems, I personally agree with
Charles' statement that "the procedures for decision making and conflict
resolution are working adequately and thus a General Resolution is not
required." Though for the purposes of curtailing further FUD and
doomsaying, I'd personally rank Lucas's and Luca's statements higher.
> > 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.
Since it *is* optional, I intentionally phrased it as such. And to be
clear, the specific work I had in mind was that some package maintainers
have gone out of their way to make their packages work on FreeBSD rather
than just waiting for patches, even though they were not required to do
so.
As someone who spent a non-trivial amount of time making XCB work on the
Hurd, I'm certainly not averse to doing such work myself where it makes
sense (i.e. for a package that aims for portability as XCB does).
> Sure, in the end *all* work on Debian is volunteer, so even a "must" in
> Policy is something "packages have been willing to [...] support".
There is no such "must" for architecture support. There is, as
previously discussed, a "should" for portability.
> >>> 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.
To the best of my knowledge, the quoted Policy text is the strongest
statement Policy makes on portability and supporting multiple
architectures, whether "any" or "more than one". There is no "must
support more than one architecture" in Policy.
> > 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.
I'd be curious to hear the source of that impression, since to the best
of my knowledge there are currently zero init-system-specific packages
in Debian (apart from init system infrastructure itself). I wouldn't be
surprised to see some such packages crop up in the future, just as I
wouldn't be surprised to see additional kernel-specific or
architecture-specific packages crop up in the future, but I also don't
expect to see half the archive depending on a specific init system
either.
So, I see no obvious evidence that this has been treated as anything
other than a "should". Not a "must", but 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?".
The distinction really doesn't matter, but fine; the equivalent of this
GR would be making it RC to not support "at least two" architectures,
which is *also* not something Policy or the project currently does.
Packages currently exist that only support one architecture, and
requests for those packages to support additional architectures would
*still* be wishlist bugs.
> > 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").
We don't need GRs for "common sense and existing practice"; we have the
Policy process for that. GRs exist as the highest dispute-resolution
mechanism for disputed issues. And this GR *is* damaging, precisely
because it *does* establish a hard requirement rather than a general
"portability is a desirable feature" "should"-level guideline. I would
consider it equally damaging to have a GR saying, for instance (based on
the current GR text): "In general, software may not require one specific
kernel.", or "In general, software may not require one specific
architecture."
As I said, if this GR was phrased as a "should" rather than a hard
requirement, I wouldn't advocate against it.
Choice is a potentially desirable feature, but not at the expense of all
else.
> >> 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.
This GR *is* specifically about systemd, and people's desire to not run
it (or, one level of indirection introduced, to preserve the ability to
not run it); if not for that motivation, the GR would not exist. The
buzzword thrown around heavily by advocates of this GR is "loose
coupling". My response above was specifically in response to the
ongoing claims that systemd's services could and should be implemented
outside of systemd.
- Josh Triplett
Reply to: