On Thu, Feb 13, 2014 at 07:55:25PM -0800, Russ Allbery wrote:
> Colin Watson <cjwat...@debian.org> writes:
> > I'm currently undecided about whether I prefer the approach of setting
> > technical policy under 6.1.1 or offering advice under 6.1.5. Bearing in
> > mind all the process discussions we've had, I can see that it might be
> > better to take the approach of offering technical advice rather than
> > getting (re-)embroiled in a distracting procedural dispute about whether
> > the Constitution entitles us to rule in advance on a subject that hasn't
> > clearly been asked of us by some other first-responding maintainer.
>
> I also think Keith's point that the normal process for setting Policy can
> probably handle this is entirely correct. Certainly, I don't think there
> will be substantial difficulties hammering out a Policy change given
> advice from the TC. If there is, we can always deal with it at that
> point.
Having slept on it a few times, my conclusion on this point is that
which power we use won't affect my decision either way. The policy team
would surely need to hammer out the exact letter of the policy in any
event (unless we're proposing that the TC's resolution should contain a
policy diff, which nobody seems to be seriously suggesting).
> > The first paragraph of the "loose coupling" section is replaced by
> > the following:
>
> > In general, software may not require a specific init system to be pid
> > 1, although degraded operation is tolerable. The exceptions to this
> > are as follows:
>
> > * alternative init system implementations
> > * special-use packages such as managers for init systems
> > * cooperating groups of packages intended for use with specific init
> > systems
>
> > provided that these are not themselves required by other software
> > whose main purpose is not the operation of a specific init system.
>
> > Maintainers are encouraged to accept technically sound patches
> > to enable improved interoperation with various init systems.
>
> There's probably no chance that I will vote any version of L above FD, so
> feel free to disregard this. But I think this is begging for some sort of
> definition of "specific."
>
> As written, it seems like it either requires all packages in the archive
> add runit configuration, since otherwise they're not supporting all init
> systems available in Debian, or alternately that any package that provides
> a runit configuration and an OpenRC configuration and depends on runit |
> openrc is fine, since it doesn't depend on "a" specific init system (it
> depends on one of two specific init systems).
>
> I don't think either of those are what you intend here. But I'm at a loss
> as to what you *do* intend. Explain it to me like I'm five? :)
What I mean by this is that software (with all the exceptions above) may
not be shipped in a configuration where you can only use it with certain
init systems. For service startup, that just means shipping sysvinit
scripts. For other interfaces, that means restricting ourselves to the
subset of interfaces that people have figured out how to make work with
other init systems as pid 1.
runit is an interesting case which I admit I hadn't really looked at
before; I assume you aren't talking about its sysvinit compatibility
mode, but rather the mode where you use it as pid 1 (e.g.
init=/sbin/runit-init). In this case, I would point out that its
documentation already says that you need to do the following when
replacing pid 1:
Step 5: Service migration
The goal is to migrate all services from sysvinit scheme to the runit
service supervision design; take a look at these [run scripts] for
popular services. The migration can be done smoothly. For those
services that are not migrated to use run scripts yet, add the
corresponding init-script startup to /etc/runit/1, e.g.:
#!/bin/sh
# one time tasks
/etc/init.d/kerneld start
/etc/init.d/rmnologin
touch /etc/runit/stopit
chmod 0 /etc/runit/stopit
It is possible to just add /etc/init.d/rc 2 for having all services
from the former runlevel 2 started as one time tasks, but keep the
goal above in mind, supervising services has great advantages.
[etc.]
So I would argue that if this is the expectation set by the init
system's own documentation, then no higher bar should be set.
Similarly, if somebody uploads a new init system to Debian which has no
sysvinit compatibility and thus does basically nothing useful to start
with, then that system is de facto RC buggy in that it can't boot a
useful Debian system, and it shouldn't be other packages' responsibility
to deal with the fact that that init system has no reasonable migration
path.
I will concede that my amendment is not terribly explicit about this.
I'm not sure how to make it more explicit without cut-and-pasting the
above into it, which I think would be a bit much. Russ, I know you said
you weren't likely to vote for this, but I don't suppose you could
suggest some language which at least makes the meaning reasonably
watertight to you per the above?
> >> For the jessie release, all packages that currently support being run
> >> under sysvinit should continue to support sysvinit unless there is no
> >> technically feasible way to do so.
>
> "packages" here should probably actually be "software" for all the reasons
> discussed elsewhere.
I agree. Russ, how about this amendment?
diff --git a/727708_initsystem/coupling-russ.txt
b/727708_initsystem/coupling-russ.txt
index 242505a..dfc1ded 100644
--- a/727708_initsystem/coupling-russ.txt
+++ b/727708_initsystem/coupling-russ.txt
@@ -2,32 +2,30 @@
Technical Committee under section 6.1.5 of the constitution. It does
not constitute an override of maintainer decisions past or future:
- Packages should normally support the default Linux init system. There
+ Software should normally support the default Linux init system. There
are some exceptional cases where lack of support for the default init
system may be appropriate, such as alternative init system
implementations, special-use packages such as managers for non-default
init systems, and cooperating groups of packages intended for use with
- non-default init systems. However, package maintainers should be
- aware that a requirement for a non-default init system will mean the
- package will be unusable for most Debian users and should normally be
- avoided.
+ non-default init systems. However, maintainers should be aware that a
+ requirement for a non-default init system will mean the software will
+ be unusable for most Debian users and should normally be avoided.
- Package maintainers are strongly encouraged to merge any contributions
- for support of any init system, and to add
- that support themselves if they're willing and capable of doing so.
- In particular, package maintainers should put a high priority on
- merging changes to support any init system which is the default on one
- of Debian's non-Linux ports.
+ Maintainers are strongly encouraged to merge any contributions for
+ support of any init system, and to add that support themselves if
+ they're willing and capable of doing so. In particular, maintainers
+ should put a high priority on merging changes to support any init
+ system which is the default on one of Debian's non-Linux ports.
- For the jessie release, all packages that currently support being run
+ For the jessie release, all software that currently supports being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so. Reasonable changes to preserve or
improve sysvinit support should be accepted through the jessie
release. There may be some loss of functionality under sysvinit if
- that loss is considered acceptable by the package maintainer and the
- package is still basically functional. All packages should support
- smooth upgrades from wheezy to jessie, including upgrades done on a
- system booted with sysvinit.
+ that loss is considered acceptable by the maintainer and the software
+ is still basically functional. All software should support smooth
+ upgrades from wheezy to jessie, including upgrades done on a system
+ booted with sysvinit.
The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
> > "Technically feasible" is so dependent on interpretation that I'm not
> > sure whether it has enough real meaning. My instinct is to borrow some
> > of the "exceptional cases" language from an earlier paragraph. On the
> > other hand, "all packages that currently support being run under
> > sysvinit" seems to mostly cover this well enough - it just takes me a
> > couple of readings to get to it. Does this sentence bother anyone else?
> > Russ, can you give an example of a package that currently supports
> > sysvinit where you would be happy that it might stop supporting it for
> > jessie due to a lack of technical feasibility?
>
> Yes: logind. I think it should be fine to package a current version of
> logind for Debian (meaning one that requires cgroups). I don't think
> logind is part of the init system implementation; it's just another
> program, like udev, that's built from the systemd source package. I don't
> think it falls into any of the other exception cases. I think it's quite
> reasonable to package a current logind for those who want to use it, even
> though, by requiring cgroups, it currently only works with a corresponding
> version of systemd as init. (Note that packaging it and having other
> packages depend on it are distinct acts with separate implications.)
>
> My understanding of the expected situation for jessie is that either
> another cgroups implementation that works under sysvinit will be available
> or someone will package logind 204 in a way that works with sysvinit.
> Given that, it will be technically feasible for GNOME to depend on a
> logind solution that doesn't require systemd. Therefore, this advice says
> that GNOME should not depend on systemd as init. (This is all totally
> obvious, of course, and I'm quite confident that the GNOME maintainers
> don't need this advice to do the right thing, which is exactly why I will
> probably be voting Keith's proposal first.)
>
> But suppose that the alternative cgroups implementation doesn't
> materialize. That specific logind implementation then *would* depend on
> systemd as init. Does that mean that a logind that uses systemd cgroups
> management is not permitted in Debian for the jessie release even if
> another version of logind is also available?
>
> Without the technically feasible qualification, this would be against our
> advice since the current packaged logind doesn't require systemd as the
> init system, and I see no reason for it to be.
So, in my amendment, I intended this to be the "cooperating groups of
packages intended for use with specific init systems", which language I
think I borrowed from your proposal. If logind-208 Depends: systemd (or
indeed if it's part of systemd), then that's fine, as long as it doesn't
end up being required by something else that isn't so intimately related
to the init system; in other words, a dependency on systemd doesn't
become any less a dependency on systemd just because it happens to be
spelled "Depends: logind" and there's only one provider available.
As I read it, then, you and I pretty much have common ground on what we
want to see happening with logind. Good.
My objection to "unless there is no technically feasible way to do so"
is that it's another way of writing "it's too hard", which could mean
almost anything, and thus the "should continue to support sysvinit"
stipulation is toothless: all a maintainer needs to do is say that it
isn't technically feasible to carry significant patches against upstream
even if somebody else writes them, and that's that. Now, maybe the
"Reasonable changes to preserve or improve sysvinit support should be
accepted ..." sentence covers this, but it seems awfully woolly to me.
I think we should list situations where dropping sysvinit support would
be permitted, as you do in the "exceptional cases" part of your
proposal. Based on this thread, one such reasonable situation would be
when a compatible implementation of the software in question remains
available (thereby forestalling confusion about whether it's still the
same software if it's been packaged under a new name).
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220005640.gb14...@riva.ucam.org
