Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> That's not the problem. The problem is the possibility of packages wich
> requires systemd's syslog replacement, its cron replacement, or its ntpd
> replacement.
This isn't a reason for a GR. This is a reason for Policy saying that
packages must not do that and must instead use our standard syslog, cron,
and ntpd facilities.
(Well, at least the latter two; I think the syslog vs. journald discussion
is more interesting and may depend somewhat on what the package does. But
we can hash that out as part of the Policy discussion. I'm certainly in
favor of any package that is logging output and doesn't already have a
hard dependency on systemd services for other reasons needing to have a
fallback to syslog if journald isn't available, at least for the time
being until we see if the landscape seriously changes like it did with
udev, in part because I think that's pretty easy to do. Maybe someone can
come up with a good reason why that's not the case, but that would
surprise me. This feels just like socket activation to me; maybe someday
we can all assume socket activation, but in the meantime that's premature,
and having the fallback in place via one means or another is not that
hard.)
I don't understand why you think you need a project-wide vote on such a
thing. Is there anyone who seriously thinks that packages should switch
to systemd *.timer units *right now* instead of putting files in
/etc/cron.d where all of our current cron systems can process them?
Policy already basically says that /etc/cron.d and related facilities are
how you do this, and I'm happy to second a proposal that makes that a must
for integration purposes. Maybe that could change in some distant future
that doesn't look like our current situation, but if so, we can change it
when that happens. The benefits of the systemd facility are minor
compared to the mechanisms we already have in place; there isn't a
logind-style driver to change ways of handling this.
I highly doubt this would even be controversial.
You seem to be both borrowing trouble and hitting it with nuclear weapons.
I assume this is coming out of your strong belief that systemd upstream is
on a crusade to replace everything, but I don't think that worry is in
much contact with reality here.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: