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

Re: Matthias's Choice 4

>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:

    Russ> Matthias Klumpp <matthias@tenstral.net> writes:
    >> However, I think it may be useful to highlight in the vote text
    >> somewhere that systemd is actually not just the init system, but
    >> a modular collection of different tools designed to work well
    >> together (many, but not all of them depending on systemd being
    >> PID 1), and that there may be benefit to the Debian operating
    >> system in deciding to adopt some of them, at least on the Linux
    >> ports.

    Russ> I strongly agree with this.
With the emphasis on "may be benefit".

    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.

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
  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.

* both option 2-3 are silent on exactly what facilities we use.  In
  general, maintainers get to use whatever facilities they like if there
  is not a project consensus against.

* 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 don't think we want to say use all facilities with no
  limitations.  As an example, I think we would need project level
  discussion to deprecate /etc/network/interfaces and move entirely to
  systemd-networkd.  So, I think we want to leave open the possibility
  that we'll have discussions in policy or elsewhere about limitations
  on systemd facilities.

* For a lot of the facilities, I don't think the project as a whole
  understands the facility enough to  make a decision here.  There are a
  couple like sysusers, socket activation and tmfiles where we probably
  do have enough understanding.  In those cases, I think the default of
  "maintainers generally get to use whatever they like," is reasonable.
  But again, I wouldn't think we'd want to go so far as to preclude
  people proposing limitations.

Reply to: