On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
> Adrian Bunk <b...@stusta.de> writes:
> > On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
>
> >> There is a natural process here, where rarely-used configurations
> >> slowly stop working and people eventually decide not to bother to keep
> >> them working and move on to other things. Eventually, they may acquire
> >> RC bugs that no one wants to fix and be dropped, or the package
> >> maintenance team may decide that they just can't support the
> >> configuration any more, make a public call for people to step forward
> >> and maintain it, and, when that call isn't answered, drop support.
>
> > The problem is different - with systemd there is a fast process going
> > on where frequently-used configurations stop working without systemd.
>
> Are you only thinking of logind with desktop environments here, or are you
> thinking of something else?
>
> I don't think this process is actually very fast (we've been arguing about
> this for at least a year), and I think you're overstating this case, but
> maybe I missed something. If you're just referring to GNOME, one desktop
> environment currently switched over doesn't strike me as very fast, and
> whether that's the path forward for that desktop environment for jessie is
> to a large extent what we're debating here.
I am not only talking about GNOME, or only about logind.
I already gave my hypothetical "udev gets a hard dependency on systemd
as init system" worst case.
To make the worst case even worse, assume a new upstream version of
systemd with this change gets released 2 weeks before the jessie freeze,
and gets uploaded into unstable immediately.[1]
In this hypothetical even worse worst case, would you consider such an
immediate upload to unstable a valid action of the Debian systemd
maintainers, or would you word the CTTE decision in a way that would
make it clear that an action like this would not be appropriate?
Note that this is a hypothetical (but not completely impossible)
example and I am not implying that the Debian systemd maintainers
would actually do such an upload in such a situation
My point is that the CTTE decision has to cover such cases, to avoid
in this hypothetical even worse worst case huge flamewars and possibly
even a GR during the freeze delaying the release of jessie.
IMHO the whole point of having a CTTE decision on the init system
question is to have the issue settled in a way that any major
disagreements can be resolved by referring to the text of the
CTTE decision.
> I think it's also important here to distinguish between decisions that
> Debian maintainers make and decisions *upstream* makes that Debian
> maintainers choose not to *reverse*. Those are two very, very different
> situations, and I think they're being treated interchangeably way too much
> in these discussions. We ask Debian maintainers to integrate their
> packages with the distribution, but we don't, in general, ask them to
> maintain long-term major forks in order to do so.
>...
The best way to avoid long-term major forks is when the Debian
maintainers make it clear to upstream that e.g. ConsoleKit codepaths
shouldn't be dropped upstream since that would make it harder for
Debian's non-Linux ports.
And in the cases where it doesn't work, it is very likely that
supporting any non-systemd init system will imply that Debian will
have to maintain or at least adopt long-term major forks.
logind is one example for such a long-term major fork.
> > And the problem is exactly that without a strong policy there will not
> > be RC bugs anywhere - when it is fine for everyone to depend on systemd,
> > then any bugs demanding support for other init systems can just be
> > tagged "wontfix" by the Debian maintainer of the package.
>
> This sounds like you're assuming a level of bad faith that I really don't
> think is appropriate. I don't want to give Debian maintainers orders in
> advance just because we're worried they might otherwise do the wrong
> thing. I think it's more likely that they'll make *better* decisions for
> their own packages when people aren't telling them specifically what to
> do, just advising on general project direction.
No, I am not assuming bad faith.
But there will be cases where the goals like
1. give users of systemd under Linux the best possible experience
2. support non-Linux ports
3. support other init systems
conflict.
What is better depends on which goal has a higher priority for you.
There shoud be a general project direction that clearly defines which
of these two goals has a higher priority for Debian, not half of the
packages going into one direction and the other half into the other
direction.
To make an example:
In my hypothetical "udev gets a hard dependency on systemd as init
system" worst case, the best decision for the Debian systemd maintainers
for their own packages might be to deliver the latest systemd to their
users immediately.
For anyone using another init system, this will be a huge pain until
some solution is found and implemented that provides a udev alternative
also usable without systemd.
> > Are in your opinion Debian's non-Linux ports part of the core
> > functionality that we should try to support?
>
> No, which is not the same thing as saying that they're not supported.
> (More than 80% of the packages I maintain are similarly not part of the
> core functionality we should try to support.)
>...
The following are two quite different options:
1. support multiple init systems since the non-Linux ports are core
functionality of Debian
2. support multiple init systems, without considering the non-Linux
ports to be core functionality of Debian that has to be protected
One major reason for people supporting multiple init systems is to allow
Debian to keep the non-Linux ports.[2] So they want 1., but might be
very surprised if it turns out what they actually got with their vote
was 2., and that the non-Linux ports might anyway die in jessie+1.[3]
And this does matter also since supporting multiple init systems will
be a lot more work than a one-time switch from sysvinit to a successor.
cu
Adrian
[1] Assuming the new systemd release is not otherwise buggy.
[2] There are also reasons why people might find 2. desirable, but it
should be clear whether they vote for 1. or 2.
[3] It is not 100% certain that this would happen with 2., but that
is clear risk that IMHO has a pretty high probability.
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
