[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

    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

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: