Quoting Cyril Brulebois (2014-11-23 13:13:05) > Jonas Smedegaard <dr@jones.dk> (2014-11-23): >> Quoting Erich Schubert (2014-11-23 09:50:12) >>> 1. There is a wide consensus that Debian continues to allow other >>> init systems. >>> 2. The installer (currently) does install systemd. >>> 3. The installer CAN be used to install sysvinit via preseeding (and >>> admins should know how to use preseeding to install systems...) >> >> I believe third point above is inaccurate: Debian-installer has hooks >> to pass hints to packages (debconf preseeding) and hooks to execute >> shell scripts. What is currently possible is only the latter: Spawn >> a shell script late in the install process to replace init-related >> packages already installed by debian-installer. > > Well, I'm really unsure what you're calling inaccurate in the third > point. It is that "preseeding" is the mechanism used - but I may indeed be wrong: I assumed the term "preseeding" meant "debconf preseeding", but realize now that indeed both <https://wiki.debian.org/DebianInstaller/Preseed> and e.g. <https://www.debian.org/releases/stable/i386/apbs01.html.en> uses the term without direct ties to debconf. Both those documents do, however, describe [not-only-debconf] preseeding as "a way to set answers to questions asked during the installation process". I consider preseeding to be feeding answers to questions before asked. Executing shell scripts is something else, IMO. You likely disagree. > I think I've mentioned that a few times already, but here's yet > another reference: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#60 Yes. And thanks for pointing to that at several occasions recently. > That's preseeding, that gives a system running sysvinit-core at the > first boot without any further interaction, replacing systemd bits by > sysvinit ones after the initial debootstrap. Ok, I understand now that preseeding not only means answering questions before asked, but also non-declarative automation. That's new to me. > If you're unhappy about the initial systemd installation, that's too > bad, because we're not going to change debootstrap, especially not at > this late stage of the release cycle, to behave differently depending > on the target distribution. The current script covers all suites from > etch (etch, lenny, squeeze, wheey, jessie, and now stretch), and it'd > really be nice if that could stay the case. I am unhappy about the need for messing non-declaratively with debian-installer in order to override default choice of init system. It is nice that debian-installer provides hooks to do dangerous things, but I find it worrisome that changing init system involves use of that. > There won't any more debconf, udeb, or whatever addition going to > happen. It means additional work (nobody has been doing that for a > whole release cycle), more maintenance, and… it's just too late. Why do you say "for a whole release cycle"? Only late in the release cycle did init system become changeable without violating policy (removing core packages). Please cc me on replies. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature