Re: [draft] Draft text on Init Systems GR
Hi Holger,
On Sat, Nov 09, 2019 at 06:09:35PM +0000, Holger Levsen wrote:
> > [Rationale: moving from systemd to sysvinit is currently an involved manual
> > process, so unavailable to anyone not already skilled in Unix
> > administration, creating an artificial barrier.]
> please clarify what you mean by this. I understand that you claim that
> "apt-get install -y sysvinit-core" is hard (I disagree somewhat, but I
> also think that those for this is hard shouldn't care) but anyway, what
> do you envision how 'automated variant transitions' should be done? A
> click in some UI?
The devil is in the details here. "apt -y install sysvinit-core" works for
the most part, but sometimes network interfaces have different names
afterwards, so doing this remotely may drop the machine off the network
(especially as systemd-networkd uses a different machine identifier than
dhclient, so dynamic IP addresses *will* change).
Another goal would be to have some mechanism that administrators for larger
sites can drop into chef/puppet and deploy it to a group of machines, and
it will return a clear success/failure indication and leave the system in a
state where it can be rebooted safely.
The same mechanism should also work in the other direction, and it should
be an abstract interface that allows us to change the implementation if
that becomes necessary.
> (This is a serious question and the reason i'm sending this mail. I'm
> really curious as I think
> https://wiki.debian.org/systemd#Installing_without_systemd is pretty
> clear and easy.)
Absulutely, yes, but it is a backdoor working through knowledge of an
implementation detail, not an interface -- so it constrains future
packaging work as people rely on this implementation detail.
> > (Option 2.2.1)
> > Core system components are excluded from backports, and backported packages
> > need to be compatible with the interfaces provided by the stable release.
> wow. I thought backports are not part of stable/optional anyway... and then, as
> pointed out before, we have versioned depends.
I've included the 2.1 and 2.2 option trees mostly as "next questions" and
to get a feeling on how people rank the importance of specific topics,
because all of these are intertwined.
As of now, we have systemd in backports, and versioned depends would pull
that into more machines. Backports policy is usually to require as few
packages that aren't in stable as possible, and I believe we have some
consensus to never do backports of core packages like libc -- which is why
I'm asking whether systemd is a core package.
> I'm glad you brought it up to this extreme. Maybe in slightly crazy
> words: yes, Debian supports smokers and non-smokers. Sometimes (often)
> not in the same place (as eg non-smokers are usually (and rightfully)
> unhappy about smoke), but still, Debian has a place^w^wplaces for both.
Yes, that would be my desired outcome: an affirmation that Debian wants to
be "universal". This has been our greatest strength for years.
> (and please dont read too much into this analogy. I'm neither saying
> systemd||sysv is like (non-)smoking. Rather I'd like us to think
> about how to integrate non-compatible things into one thing, Debian.)
That is a technical challenge, IMO solvable once we have a consensus on
that "the project" wants that.
> ;tl;dr: policy *should*, but not must. recommendations.
Yes, I see these more as "adjusting expectations", which is why I started
the major options with "The Debian project aims at".
Simon
Reply to: