On Tue, Oct 28, 2014 at 06:31:43PM +0200, Aigars Mahinovs wrote: > On 28 October 2014 18:20, Russ Allbery <rra@debian.org> wrote: > > With all of those facilities, we've taken different approaches; with the > > mail transport agent, for example, we've defined an interface that all > > mail transport agents are required to implement, and MTA implementations > > that don't implement that interface aren't allowed to provide a mail > > transport agent. We did something similar with /bin/sh. With udev, on > > the other hand, we basically required everyone run udev; it's > > theoretically possible to boot a system without udev, but it's not tested > > and I think everyone would agree that it's not supported. For the > > compiler, all of Debian is built with GCC, but some teams do test builds > > with Clang and report bugs, which most maintainers merge and some don't. > > And with libc, we do not even allow for the possibility of replacing the > > system libc; you use glibc if you're using Debian on Linux, and that's the > > end of that. > > This is an interesting insight. It also can be used to identify > possible solutions for the current issue: > * if we go the MTA/sh route, then we define lowest common denominator > interface of an init system and only init systems providing that > (possibly with a systemd-shim) can be init systems in the archive and > also applications can only depend on presence of these particular > interfaces; > * if we go udev/gcc/glibc route, then we just say that all other init > systems are not supported, put systemd as essential and push all other > init systems to extra or even out of the archive; > > With enough imagination it is possible to see the original GR proposal > as implementing the first option in a obtuse way. I think there's possibly a slight logic gap here, and that's around "applications can only depend on presence of these particular interfaces". As far as I'm aware, we don't actually say that anywhere. Applications can only /rely/ on those interfaces, but it's certainly possible for an application to have a Depends: on a particular shell. From Policy 10.4: "If a shell script requires non-SUSv3 features from the shell interpreter other than those listed above, the appropriate shell must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked "Essential", as in the case of bash)." Going down the minimal standard would mean that we should codify in policy what we expect the minimal standard of the init system to have to be in the archive, but what this GR seems to be about is saying that applications may or may not actually have that Depends: at all. Neil --
Attachment:
signature.asc
Description: Digital signature