Re: Matthias's Choice 4
Sam Hartman <hartmans@debian.org> writes:
>>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
> Russ> Right now, I think all three options that Sam put forward as a
> Russ> draft are insufficient because they aren't sufficiently clear
> Russ> on how we intend to handle the other plumbing and facilities
> Russ> that the systemd project is maintaining.
> I agree option 1 is less clear on this poin than I'd like.
> I'd love for someone to propose wording.
Option 1 in your draft says that not including an init script to start a
daemon is a bug but not an RC bug. It is silent on all non-daemon uses of
the init system, and is silent on elogind as well. Trying to extrapolate
from what it says about init scripts, I think a consistent statement would
be something like:
systemd unit files included in the package may use any systemd feature
or service at the package maintainer's discretion, provided that this
is consistent with other Policy requirements and the normal
expectation that packages shouldn't depend on experimental or
unsupported (in Debian) features of other packages.
Init scripts must use only facilities common to all supported init
systems in Debian and therefore may not use services that depend on
systemd.
Similarly, packages may freely use other systemd services such as
timer units, subject to the above constraints, but not also supporting
non-sysemd systems is a (non-RC) bug and non-maintainer uploads to add
that support are appropriate.
Obviously I defer to the folks working on init system diversity if they
want to write the text instead.
> I actually think options 2 and 3 are fairly clear on this point. I
> acknowledge more emphasis may be required. That is, I think the options
> state a position, but it's probably easy to read them and not realize
> that.
> * Options 2-3 say that maintainers may accept alternatives to systemd
> facilities.
> That means that it's reasonable to use facilities provided by systemd,
> and that it's not a bug if your package only works under systemd.
> People can submit patches if they wish you used less systemd
> facilities and you can consider those patches just as you would any
> patch.
I think it would be better if exactly that language were included in both
options 2 and 3, because this is not obvious to me from their text.
Specifically, I think both should say something like the above:
Packages may freely use any systemd service at the package
maintainer's discretion, provided that this is consistent with other
Policy requirements and the normal expectation that packages shouldn't
depend on experimental or unsupported (in Debian) features of other
packages.
As Policy Editor, this means that if options 2 or 3 won, I would consider
that a request from the project to start documenting and recommending use
of systemd facilities that make sense and provide advantages over current
facilities. This will definitely include DynamicUser, and would probably
include systemd-tmpfiles and systemd-sysusers, among other things.
If option 1 wins, this is trickier, because option 1 sends mixed messages.
Those facilities are potentially usable by maintainers but are also buggy
without fallbacks, so facilities without implemented fallbacks would feel
wrong to recommend in Policy. Therefore, I think the implication would be
that we would only recommend adopting systemd services for which someone
had already implemented equivalent functionality (but *not* necessarily
unit parsing or any other tighter integration with systemd configuration)
for other supported init systems.
Dmitry's alternate option 1 is far clearer, btw, and much easier for me to
interpret for writing Policy language, although I still have questions as
noted in that other thread.
> * I don't think we're in a position to explicitly enumerate what
> facilities to use here in this GR, so I don't think there is a lot
> more to say.
I agree that we don't want to enumerate them. What I want is for the GR
to clearly choose between four options:
a. Requiring systemd facilities that do not have an equivalent
implementation for other init systems is prohibited. Optionally using
systemd facilities if available is allowed, but there must be a
fallback for non-systemd systems that provides basic functionality.
(In other words, it's fine to use namespaces and syscall filters if
available even though they're not supported on sysvinit, but it's not
okay to use timer units unless you also ship a cron job and arrange for
it to be run as a fallback, and it's not okay to assume that
systemd-tmpfiles will be run.)
b. systemd facilities may be used at the discretion of package
maintainers, but modification of Policy to adopt systemd facilities
instead of existing approaches is discouraged unless an equivalent
implementation of that facility is available for other init systems.
This means that Policy will continue to require various aspects of
system configuration to be done in the way they are done now (such as
creating system users) until such time as new approaches are
implemented for all supported init systems. Therefore, package
adoption of new facilities will mostly be for things not standardized
by Policy, or cases where one behavior is be chosen if the systemd
unit is used but another behavior is chosen if a facility is started by
an init script.
c. systemd facilities may be used except where Policy says to use
something else, and the Policy editors are free to modify Policy to
recommend or require use of the systemd facilities rather than the
existing approach. However, this should be done in a way that
alternative implementations of those facilities can be supported, such
as by standardizing the configuration language to match systemd but
leaving open what program will interpret and implement that
configuration. The burden is on maintainers of alternate init systems
to keep pace with those changes and provide equivalent functionality
using the same package configuration files. Lack of such functionality
is not an argument against changing Policy to adopt systemd facilities.
d. systemd facilities, where they exist and are stable and supported by
the systemd maintainers, should be preferred over Debian-specific ways
of solving the same problem unless the Debian approach has clear and
obvious advantages. Policy editors should begin work on documenting
those facilities, recommending or requiring their use as appropriate,
and phasing out Debian-specific approaches that are functionally
equivalent or inferior. The project will not attempt to support
non-systemd systems.
I believe that you intend for your option 1 to say my option b, and your
options 2 and 3 to say my option c. Is that correct?
If so, I think my options a and d are possibly viable choices for the
project that are currently not represented on this ballot. I believe
Dmitry's alternate wording for option 1 is intended to indicate my option
a (although it could use some clarification).
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: