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
