Re: ***UNCHECKED*** Re: [draft] Draft text on Init Systems GR
Hi, On Sun, Nov 10, 2019 at 12:19:24AM +0100, Bernd Zeimetz wrote: > > Yes, that would be my desired outcome: an affirmation that Debian wants to > > be "universal". This has been our greatest strength for years. > Its a strength that wasted an enormous amount of ressources. See > kfreebsd (which was actually really nice!) and Hurd, to name some > prominent examples. Taking this to the extreme, it is an enormous waste of resources to maintain both Debian and Ubuntu as separate entities. What differentiates us? > People should not be forced to waste their time, but also we should not > necessarily stop them if they want to do it. The problem is at the intersection when one person considers it a waste of their time when they are asked to integrate the work of another person, whose work is wasted if it is not integrated. > For me I think the only useful way would be to maintain all init-scripts > in a single package that gets pulled in with sysvinit. Whoever wants to > use and maintain it is free to do so. Initscript could actually be > installed using dpkg triggers or whatever else works. You are still missing the point. This is not a technical problem, and providing a technical solution... > (And at some time we can still move that package into an external > repository). ... that essentially tells people to leave the project if they disagree with you is not a solution for a social problem, quite the opposite in fact. Simon
Re: [draft] Draft text on Init Systems GR
On 11/9/19 11:24 PM, Simon Richter wrote: > Yes, that would be my desired outcome: an affirmation that Debian wants to > be "universal". This has been our greatest strength for years. Its a strength that wasted an enormous amount of ressources. See kfreebsd (which was actually really nice!) and Hurd, to name some prominent examples. People should not be forced to waste their time, but also we should not necessarily stop them if they want to do it. For me I think the only useful way would be to maintain all init-scripts in a single package that gets pulled in with sysvinit. Whoever wants to use and maintain it is free to do so. Initscript could actually be installed using dpkg triggers or whatever else works. (And at some time we can still move that package into an external repository). -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: [draft] Draft text on Init Systems GR
Am Sa., 9. Nov. 2019 um 23:01 Uhr schrieb Mike Gabriel : > [...] > Isn't as side-question that is on the table with this GR: what about > the future of non-Linux variants of Debian. If systemd becomes _the_ > init system of focus in Debian (by vote, not only de facto), kFreeBSD > and Hurd will certainly have more of their difficulties, more than > they have now. > [...] This comes up often, but I don't think this is actually that big of a deal: kFreeBSD & Co. already require a lot of other changes in packages, related to facilities (DBus services, syscalls, etc.) not available on these platforms. While all Linux ports could use systemd, the kFreeBSD/Hurd architectures could continue using sysvinit, and packages could conditionally install init-scripts only on the kFreeBSD architecture. This also avoids dependency issues and problems caused by switching out init. Note that I am not saying "this is what should be done", just that in case we *would* go all-in on systemd, this in no way would mean the death of non-Linux ports. Sure, they would be slightly harder to maintain, but they are already a hard thing to do, and compared to porting stuff that uses Linux syscalls, the init issue isn't that much different. The one thing I am against though is the non-Linux ports holding back innovation and experimentation on the Linux ports. If we go with the lowest common denominator, we can't realistically move forward, ever. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: [draft] Draft text on Init Systems GR
Hi Mike, On Sat, Nov 09, 2019 at 09:48:03PM +, Mike Gabriel wrote: > root@minobo:~# apt-rdepends -r systemd | wc -l > 6598 It's not as bad as you think: the important package is systemd-sysv. In buster: $ apt-cache rdepends systemd-sysv In bullseye: systemd-sysv Reverse Depends: systemd-cron dbus-user-session |xfce4-session |unattended-upgrades sysvinit-core sysvinit-core libvirt-daemon-system udev libpam-systemd runit-systemd runit-init runit-init prometheus-postgres-exporter prometheus-node-exporter prometheus-bind-exporter prometheus-apache-exporter prometheus-alertmanager prometheus profile-sync-daemon pk4 |numad munin micro-httpd mender-client |mandos logrotate dbus-user-session |libguestfs0 |init gpsd friendly-recovery exim4-base The lines marked with a | have an alternative, e.g. numad has ..., systemd-sysv | cgmanager, ... Several of these are not Depends, but Conflicts/Replaces relationships, but I have no idea how to quickly filter them, and several like exim4-base have alternatives, but these aren't shown here. What I can confirm depends on systemd-sysv are - systemd-cron (not relevant, we have cron) - dbus-user-session (can be replaced by dbus-x11, although apt doesn't find that solution) - libvirt-daemon-system (real problem) - udev (not relevant, we have eudev) - libpam-systemd (not relevant, that is the integration for dbus-user-session & co) So the only real issues at the moment are libvirt-daemon-system and apt needing a manual poke when installing something that pulls in dbus-user-session, such as libgtk. Simon
Re: [draft] Draft text on Init Systems GR
Hi, On Do 07 Nov 2019 19:59:49 CET, Sam Hartman wrote: No, the difference intended between choice 2 and 3 is about how we handle technologies like elogind, or a mythical technology that parsed sysusers files, rather than how we handle starting daemons. I'd suggest leaving elogind entirely out of the discussion, here. The elogind fork of the systemd component systemd-logind only kicks in, just like systemd-logind, once a user logs into the session. As I get it, the rest of the GR draft is about system services initialization, not user session services startups. If systemd was mandatory, user session services would be handled by systemd-logind. If systemd was replaceable by some other init system, than there would be (at least) two options: - still use systemd-logind for user session service startups (and have all the systemd entanglement package-wise) [1, 2] - use elogind (drop-in replacement for systemd-logind, no entanglement with systemd as a system service orchestrator) Isn't as side-question that is on the table with this GR: what about the future of non-Linux variants of Debian. If systemd becomes _the_ init system of focus in Debian (by vote, not only de facto), kFreeBSD and Hurd will certainly have more of their difficulties, more than they have now. light+love, Mike [1] in Debian jessie this was possible [2] Ubuntu used to have a phase when upstart was handling system services and systemd-logind was handling user session services -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpFxlp1eGHIc.pgp Description: Digitale PGP-Signatur
Re: [draft] Draft text on Init Systems GR
On Sa 09 Nov 2019 19:09:35 CET, Holger Levsen wrote: On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote: (Option 1.1.1) Automated variant transitions shall be supported. [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? (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.) The problem here is this (queried on a buster system): ``` root@minobo:~# apt-rdepends -r systemd systemd Reverse Depends: 389-ds-base (1.4.0.21-1) Reverse Depends: apticron-systemd (1.2.1) Reverse Depends: arctica-greeter (0.99.1.3-1) Reverse Depends: ayatana-indicator-session (0.4.3-2) Reverse Depends: biometric-auth (0.9.61-2) Reverse Depends: biometric-utils (0.9.61-2) Reverse Depends: btrfsmaintenance (0.4.2-1) Reverse Depends: clevis-systemd (11-2) Reverse Depends: cloudprint-service (0.14-12) Reverse Depends: dbus-user-session (1.12.16-1) Reverse Depends: fakemachine (0.0~git20181105.9316584-2) Reverse Depends: fcgiwrap (1.1.0-12) Reverse Depends: iio-sensor-proxy (2.4-2) Reverse Depends: kde-config-systemd (>= 1.2.1-3) Reverse Depends: libbiometric-dev (0.9.61-2) Reverse Depends: libbiometric0 (0.9.61-2) Reverse Depends: liblxc1 (1:3.1.0+really3.0.3-8) Reverse Depends: libnss-resolve (= 241-7~deb10u1) Reverse Depends: libnss-systemd (= 241-7~deb10u1) Reverse Depends: libpam-systemd (= 241-7~deb10u1) Reverse Depends: libreswan (3.27-6) Reverse Depends: live-config-systemd (5.20190519) Reverse Depends: local-apt-repository (0.6) Reverse Depends: ltsp-client (>= 5.18.12-3) Reverse Depends: mate-power-manager (1.20.3-2) Reverse Depends: netplan.io (>= 0.95-2) Reverse Depends: ntpsec-ntpviz (1.1.3+dfsg1-2) Reverse Depends: oddjob (0.34.4-1) Reverse Depends: open-infrastructure-system-config (20190202-1) Reverse Depends: openvpn-systemd-resolved (>= 1.2.7-1) Reverse Depends: plymouth (>= 0.9.4-1.1) Reverse Depends: python-ipalib (4.7.2-3) Reverse Depends: rasdaemon (0.6.0-1.2) Reverse Depends: snapd (2.37.4-1+b1) Reverse Depends: sogo (4.0.7-1) Reverse Depends: systemd-container (= 241-7~deb10u1) Reverse Depends: systemd-coredump (= 241-7~deb10u1) Reverse Depends: systemd-journal-remote (= 241-7~deb10u1) Reverse Depends: systemd-tests (= 241-7~deb10u1) Reverse Depends: tomcat9 (>= 9.0.16-4) Reverse Depends: ukui-power-manager (1.1.2-1) Reverse Depends: vblade (24-3) Reverse PreDepends: systemd-sysv (241-7~deb10u1) [...] ``` Output has been shortened to the first layer of the dependency tree. ``` root@minobo:~# apt-rdepends -r systemd | wc -l Reading package lists... Done Building dependency tree Reading state information... Done 6598 ``` The previous command would print out 6598 lines, in fact. We have several packages that hard-depend on systemd. IMHO, all of those should be investigated, if such a hard dependency could not be avoided. (In fact, arctica-greeter and mate-power-manager could indeed live without it). For iio-proxy-sensor, I just did an NMU that dropped the hard systemd dependency. On my local notebook (on buster), a switch to sysvinit-core would to this... ``` root@minobo:~# apt-get install sysvinit-core Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: accountsservice appstream apt-config-icons apt-config-icons-large argyll bluefish-data bluefish-plugins bolt brasero-cdrkit breeze-cursor-theme caja-common catdoc cinnamon-common cinnamon-control-center-data cinnamon-screensaver cinnamon-screensaver-x-plugin cinnamon-settings-daemon cjs colord-data dvd+rw-tools evemu-tools evtest gir1.2-abi-3.0 gir1.2-cinnamondesktop-3.0 gir1.2-clutter-gst-3.0 gir1.2-cmenu-3.0 gir1.2-cvc-1.0 gir1.2-dazzle-1.0 gir1.2-gdm-1.0 gir1.2-gnomebluetooth-1.0 gir1.2-grilo-0.3 gir1.2-gsf-1 gir1.2-keybinder-3.0 gir1.2-mediaart-2.0 gir1.2-meta-muffin-0.0 gir1.2-mutter-3 gir1.2-packagekitglib-1.0 gir1.2-pluma-1.0 gir1.2-xapp-1.0 gnome-session-bin gnome-session-common growisofs hwdata iso-flags-png-320x240 k3b-data kate5-data katepart kde-cli-tools-data kde-style-qtcurve-qt4 kded5 kdelibs-bin kdoctools kdoctools5 khotkeys-data kio-extras-data kpackagetool5 ksysguard-data ksysguardd ktexteditor-data kwin-data kwrited libappstream4 libappstreamqt2 libblockdev-fs2 libblockdev-loop2 libblockdev-part-err2
Re: [draft] Draft text on Init Systems GR
Hi, On Sat, Nov 09, 2019 at 10:01:27AM -0800, Russ Allbery wrote: > > (Option 1) > > The Debian Project aims at providing the greatest configuration flexibility > > while maintaining a sensible default installation for end users. To that > > end, we document functional dependencies in a machine-readable way and > > provide alternative variants if possible. > "Functional dependencies" feels odd to me as a way of characterizing this > whole problem space. I can kind of see where you're coming from with > that, but it's about more than dependencies. It's also about configuring > the environment in which a service should run and controlling the > mechanisms of starting the service and determining when it should be > running. Yes, but all of these can be boiled down to required interfaces, "can I express the desired environment and start conditions in the terms of this interface?" Interfaces are versioned, however, and we need either a negotiation process or a mechanism to avoid version mismatch. With a slow-moving interface like sysvinit's, that was not a problem, but systemd evolves faster than Debian releases. Negotiation is out for static unit files, so that leaves a lockout mechanism. In the "full diversity" case, we'd ideally map the required interfaces onto package relationships, e.g. Depends: interface-systemd-timer-unit-1 (>= 4) Here, 1 and 4 are the version numbers for the interface -- no compatibility breaks yet, but the unit file uses declarations added in a later revision. This mechanism could work similar to shared libraries with symbol versions, and the usual Conflicts/Provides mechanism would make sure that only one provider for each interface is installed. Long term, init scripts would lose their special status and require a dependency declaration as well, which could be used to decide if systemd generators for init compatibility are needed. A package providing both an init script and a service unit file would declare that it requires either, and thus would not force anyone to install compatibility code. > The phrasing here doesn't really address how aggressive we're going to be > about using systemd services. I think "if possible" is doing a bit too > much heavy lifting and not providing enough guidance. The default would still remain systemd. Alternative implementations will only appear if there is interest in having them, so there is no point in binding the project into providing them with no users. My expectation is that alternative implementations will pick and choose what interfaces to implement, based on users' needs and feasibility. Basically, if the sysvinit users are mostly running system services on headless boxes, then there is no need to provide an implementation of dbus-activated session services. > > (Option 1.1.1) > > Automated variant transitions shall be supported. > > [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.] > Doesn't this have that same problem that it votes for creating an RC bug > that we have no real idea how to fix? Probably a package that diverts /sbin/init and replaces it with a shell script that checks if a transition is pending and performs it if all requirements are met (e.g. required packages available in apt cache and checksums correct, ...). No need to do this in existing packages. > In general, for these variants, is the transition path from systemd to > sysvinit something that is controversial in the project? I thought the > problem was mostly ensuring things work on sysvinit at all. The transition path is important as long as the installer installs systemd by default and this cannot be changed (which would be option 1.1.3). The number "1% of new installations use sysvinit" is floating around. In absolute terms, that is a massive number of people who went through a long manual process, and making that process less painful would be a great service. > > (Option 1.2.1) > > Package maintainers for packages requiring tighter integration into a > > particular ecosystem are asked to form teams to cover adequate > > integration testing. > I truly have no idea what this means, what Policy language it would > translate into, or what work this implies a Debian package maintainer > should do. As for Policy, not much, since that is an organizational, not a technical thing. My expectation is that services that require more complex integration than "start process (after rcS.d|before multi-user.target)" will be team-maintained anyway, and this is expressing a wish that if a volunteer pops up who is using that service on a sysvinit box and they are remotely competent, they get added to the team as the go-to person for sysvinit integration. That doesn't necessitate commit access, but likely will, and it probably implies a mail "I'm about to upload a new upstream release, can you check if it
Re: [draft] Draft text on Init Systems GR
Simon Richter writes: > the main problem I see with this GR is that it is in essence a rehash of > the GR[1] we had in 2014, with pretty much the same options minus the > one that won, "A GR is not required." I voted that option in 2014 and definitely will not be voting that option today, for the reasons explained in another thread on debian-devel. If there are a sufficient number of people like myself who feel that way now, this isn't really a rehash. It's five years later; some things have changed and we understand more about the problem space. > The fact that only service start is documented in policy is a bug in > itself. There are numerous bugs in Policy in this area and a truly huge amount of work that needs to be done. On to your proposal > (Option 1) > The Debian Project aims at providing the greatest configuration flexibility > while maintaining a sensible default installation for end users. To that > end, we document functional dependencies in a machine-readable way and > provide alternative variants if possible. "Functional dependencies" feels odd to me as a way of characterizing this whole problem space. I can kind of see where you're coming from with that, but it's about more than dependencies. It's also about configuring the environment in which a service should run and controlling the mechanisms of starting the service and determining when it should be running. The phrasing here doesn't really address how aggressive we're going to be about using systemd services. I think "if possible" is doing a bit too much heavy lifting and not providing enough guidance. > (Option 1.1.1) > Automated variant transitions shall be supported. > [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.] Doesn't this have that same problem that it votes for creating an RC bug that we have no real idea how to fix? In general, for these variants, is the transition path from systemd to sysvinit something that is controversial in the project? I thought the problem was mostly ensuring things work on sysvinit at all. > (Option 1.2.1) > Package maintainers for packages requiring tighter integration into a > particular ecosystem are asked to form teams to cover adequate > integration testing. I truly have no idea what this means, what Policy language it would translate into, or what work this implies a Debian package maintainer should do. > (Option 1.2.3) > The same software may be packaged multiple times by different > maintainers if integration requirements cause incompatibilities. > [Rationale: this allows packaging to be kept simple, at the expense of > some space in the archive] This seems fraught with technical peril. Are we sure our package dependency resolution code is capable of dealing with this tangle of Conflicts and Provides? > (Option 2) > The Debian project aims at providing a tightly integrated operating > system, standardizing on specific components to ensure the availability > of basic functionality. I think it would be interesting to have this sort of "all in on systemd" option on the ballot to understand how many people in the project may feel this way but be unwilling to wade into the interminable threads, although it feels kind of aggressive as only one of two choices. Also, I think that if this is about standardizing on systemd, we should just say that, as opposed to speaking in generic terms. > (Option 2.1.1) > The available interfaces for each Debian release are defined in Debian > Policy. > [Rationale: this is how we have always done it: Policy explains the > interfaces for package integration] > (Option 2.1.2) > The available interfaces for each Debian release are defined by the > maintainers of the packages providing them. > [Rationale: the maintainers of these packages have the best overview > over which interfaces can be best supported for the support period of a > release.] We've always done a combination of these two things based on a lot of factors: how foundational the interface is, how much time the relevant teams have, etc. I'm not sure it makes sense to collapse this waveform quite this definitively. > (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. > [Rationale: it's a stable release.] > (Option 2.2.2) > It is permissible for backports to declare a dependency on a newer > version of a core system component. Users installing a backported > version of a service may be required to pull in backports of other > packages. > [Rationale: interfaces change, and it may not always be possible to > combine two components from different releases] This is an interesting question but I'm not sure it needs to be decided by GR. Is this really that controversial? I'm not sure we've spent much
Re: [draft] Draft text on Init Systems GR
On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote: > the main problem I see with this GR is that it is in essence a rehash of > the GR[1] we had in 2014, with pretty much the same options minus the one > that won, "A GR is not required." The option that won is worded like this: """ The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote. Regarding the subject of this ballot, the Project affirms that the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required. """ Are we still sure that the procedures are working adequately? -- WBR, wRAR signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
Hi, the main problem I see with this GR is that it is in essence a rehash of the GR[1] we had in 2014, with pretty much the same options minus the one that won, "A GR is not required." > Choice 1: Affirm Init Diversity The way this is worded is even stronger than in the 2014 GR, which made allowances for degraded operation, because it was already obvious then that GNOME would tightly integrate with systemd. We cannot sensibly pass this as a resolution because it would create tons of highly complex RC bugs, something the 2014 GR proposal explicitly avoided, so this would just set us up for another GR reversing the decision in light of its total unworkability. > Being able to run Debian systems with init systems other than systemd > continues to be something that the project values. With one > exception, the Debian Project affirms the current policy on init > scripts and starting daemons (policy 9.3.2, 9.11). This is the smallest part of the problem. If it was about starting daemons, we'd have found a solution already. The question is what we do with packages that have an explicit functional dependency on a particular feature only implemented in one particular service orchestrator (because systemd is definitely more than a pure init system, it just happens to include one as a byproduct). The fact that only service start is documented in policy is a bug in itself. The question at this point is no longer "which init system do we want to have", but "who sets policy for package integration?" -- and that is a question that will have to be answered even in a systemd-only ecosystem. So as a counterproposal, two major directions for diversity yes/no (with no middle ground, and two further questions for each, then flattened out to make use of the fact that we're using Condorcet and don't have to deal with tactical voting. (Common) The Debian Project recognizes that several upstream software projects are converging on a common service orchestrator architecture and therefore require distribution maintainers to ensure that compatible interfaces are provided when the software is installed. At the same time, users are deploying Debian in environments where a hard dependency on a specific service orchestrator either introduces additional complexity or conflicts with other software. [Rationale: we want to be the universal operating system, which includes desktop, server, container and embedded setups, probably a few others, and mixes between them. For desktop users, we need a default installation that is fully functional, but container solutions have their own dependency tracking across machines, and will make different decisions on which services to deploy where than a standalone desktop system would make.] (Option 1) The Debian Project aims at providing the greatest configuration flexibility while maintaining a sensible default installation for end users. To that end, we document functional dependencies in a machine-readable way and provide alternative variants if possible. [Rationale: not every combination of software makes sense or has sufficient interest to be maintained, and that is okay, but if there are users, we should try to support them.] (Option 1.1.1) Automated variant transitions shall be supported. [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.] (Option 1.1.2) Moving installations between variants shall be supported. [Rationale: this is what we have now, so it probably should be an option] (Option 1.1.3) Installation variant is decided at installation time and there is no expectation that this can be altered later. [Rationale: this allows us to write package dependencies without regard for conversion paths, and also gives administrators a scriptable path for deployments, which they currently do not have.] (Option 1.2.1) Package maintainers for packages requiring tighter integration into a particular ecosystem are asked to form teams to cover adequate integration testing. [Rationale: we're moving towards team maintenance in git anyway for many packages. If someone volunteers to maintain a particular variant that they also use, then that should probably work.] (Option 1.2.2) Package maintainers are asked to merge patches implementing support for different ecosystems. Bug reports for problems arising on these variants may be forwarded if they are packaging related. [Rationale: this is like team maintenance, but with a hierarchy and lower barrier to entry, in the hope that derived distributions send patches to minimize differences] (Option 1.2.3) The same software may be packaged multiple times by different maintainers if integration requirements cause incompatibilities. [Rationale: this allows packaging to be kept simple, at the expense of some space in the archive] (Option 2) The Debian project aims at providing a tightly integrated
Re: [draft] Draft text on Init Systems GR
Hello Wouter, Wouter Verhelst [2019-11-09 10:32 +0200]: > > Choice 1: Affirm Init Diversity > > > > Being able to run Debian systems with init systems other than systemd > > continues to be something that the project values. With one > > exception, the Debian Project affirms the current policy on init > > scripts and starting daemons (policy 9.3.2, 9.11). Roughly, packages > > should include init scripts to start services that are included. > > Policy notes that early boot services like those started from > > /etc/rcS.d may be tied closely to the init system in use. > > I don't see why this is relevant in the current discussion. > > My nbd-client package is one that is relevant here; it has a systemd > unit, and an rcS init script (which is then ignored by systemd). If this > choice wins, then init scripts remain mandatory. If you provide an rcS > init script, then systemd units are also mandatory. IMHO early-boot services in rcS.d are one of the most important aspects of this entire discussion. Late boot services are generally easy, as the vast majority have simple dependencies and simple startup logic in the sense of how deeply they need to interact with the guts of the OS. Ignoring systemd features like privilege reduction/isolation/robustness, a systemd unit and a SysV script that uses /lib/init/init-d-script have roughly the same complexity. They are reasonably easy to test on both a systemd and a SysV init system, and it's the right thing to let them be maintained by the individual package maintainers. But this picture is entirely different in early boot (rcS.d, or sysinit.target): these have complex, brittle, and dynamic dependencies, are hardware/install type/configuration dependent, and require an integrative cross-package design, development, and maintenance. This is the part where SysV init scripts and distributed maintenance are desperately bad, and why a lot of configurations had been so buggy or impossible for many years. They suffer from imperative shell script hell and not enough machine readability/introspectability/uniformity to reason about or validate them. For these a distributed maintenance approach has been shown to not work well; integrating NetworkManager, LUKS, NFS, LVM, RAID, dynamic partition type detection, udev, X.org/wayland/login managers etc. needs to be a primary responsibility of the team that maintains the init system itself [1]. These need comprehensive system integration tests [2] with lots of different scenarios. This is the one thing in that GR that I have a strong opinion on (backed by doing *two* init system migrations in my life): Choice 1 is a non-starter if it mandates distributed SysV init script maintenance for early-boot services. If these are exept, and maintained/QAed by the corresponding init system, then Choice 1 is very sensible and practical. I wish that the GR text could expand on that a little bit, but I do appreciate that this quickly gets into the trenches of deep technical details. For now I interpret the last sentence as a sufficient exception (avoiding the word "loophole") for that scenario. > So this is not an exception to the rule? It just means you have more > work to do. What do you mean by "more work to do"? I. e. what and who? Thanks, Martin [1] That of course doesn't mean that the package maintainer doesn't have a say in that -- they absolutely do. But to a large degree they need to trust and defer to the maintainers of the init system. [2] autopkgtests can also do that -- I wish we had had what we have today in the upstart/early systemd times!
Re: [draft] Draft text on Init Systems GR
Hello all, Sam Hartman [2019-11-07 13:04 -0500]: > I hope my actions demonstrate that I've tried to work with and understand the > needs of all sides here; that has been my intent. Many thanks! (Again, in public now :-) ) Full disclosure: I discussed that with Sam in private before, as representative of the systemd maintainers. > Choice 1: Affirm Init Diversity > > Being able to run Debian systems with init systems other than systemd > continues to be something that the project values. With one > exception, the Debian Project affirms the current policy on init > scripts and starting daemons (policy 9.3.2, 9.11). To clarify: Is the exception to alter the "must" in the current policy, that says However, any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script ? > Roughly, packages should include init scripts to start services that are > included. I. e. changing "must" to "should", and thus stop making packages like cockpit have an RC bug. cockpit has deep systemd dependencies both for startup and at runtime -- support for non-systemd will not happen. So even choice 1 would mean to move from "everything in Debian must work with SysVinit" to "we accept that there are some packages in the archive which only work with systemd". This may soon apply to GNOME as well: https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/ > Policy editors are requested to amend policy; including a service unit > without an init script is appropriate for a non-maintainer upload but > should no longer be an RC bug. This is ambiguous: I think you mean that "a package having a service unit but without an init script is no longer an RC bug", not that the process of *including* a service unit is an RC bug. So how about a package having a service unit but without an init script is no longer an RC bug, but including an init script is appropriate for a non-maintainer upload. ? > Policy editors are requested to consider whether there are cases where > removing an init script that used to be provided should be RC because it > would break a system on upgrade. +1 that makes absolute sense for Choice 1. Thanks, Martin signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: > > This is a draft GR. I hope to be at a point where I could formally > propose a GR in a week, assuming discussion converges that fast. You can formally propose a GR today, and I recommend you do -- otherwise we end up discussing things before the discussion period, and then you need to sit and wait at least seven days during the *actual* discussion period for no good reason. Note that "proposing a GR" does not imply "calling for the vote"; that happens later, after the GR has been properly drafted and discussion on all amendments has ended. Note also that every accepted amendment resets the discussion period, and that while you have the ability (as DPL) to accept amendments without seconds, and to vary the discussion period by up to a week, you do not have the ability to eliminate the discussion period altogether. Therefore it would make sense to have a formal GR proposal today so tha amendments can be made. > At this point, the question is whether the choices that need to be on > the ballot are represented in this draft GR. > > I did not obtain a review of this version from someone who favors init > diversity. In my opinion, our GR procedure works best if every choice on the ballot was drafted by someone who actually wants it to happen; otherwise you run the risk of two problems: - You may end up with options on the ballot that don't actually represent the opinion of *any* developer, *at all*. This represents clutter, and needlessly wastes time of voting developers who will have to wade through reading a (number of) useless options that nobody really wants. - You will need to judge whether any proposed amendment matches the opinion of anyone who previously already agreed with that option, when you are not in the best position to do so. Every time you accept (or reject) an amendment, you run the risk of alienating whoever actually agreed with that proposal, possibly resulting in them proposing their own alternate option. This almost ended up happening for GR 2004_004, and that one was a mess. Given your above statement, I'm assuming that your preferred option is #3. Is that correct? > I didn't give them a lot of time, and they just wrote to let > me know that they weren't going to be able to do a review this week. > Based on the feedback from debian-devel I decided that getting text to > the community now was the most important thing. > If this text doesn't meet the needs of that community, we'll change the > text. I hope my actions demonstrate that I've tried to work with and > understand the needs of all sides here; that has been my intent. > > > > version 2330c05afa4 > > Using its power under Constitution section 4.1 (5), the project issues > the following statement describing our current position on Init > systems, Init system diversity, and the use of systemd features. This > statement describes the position of the project at the time it is > adopted. That position may evolve as time passes without the need to > resort to future general resolutions. The GR process remains > available if the project needs a decision and cannot come to a > consensus. > > Choice 1: Affirm Init Diversity > > Being able to run Debian systems with init systems other than systemd > continues to be something that the project values. With one > exception, the Debian Project affirms the current policy on init > scripts and starting daemons (policy 9.3.2, 9.11). Roughly, packages > should include init scripts to start services that are included. > Policy notes that early boot services like those started from > /etc/rcS.d may be tied closely to the init system in use. I don't see why this is relevant in the current discussion. My nbd-client package is one that is relevant here; it has a systemd unit, and an rcS init script (which is then ignored by systemd). If this choice wins, then init scripts remain mandatory. If you provide an rcS init script, then systemd units are also mandatory. So this is not an exception to the rule? It just means you have more work to do. > Init > scripts are the lowest common denominator across all init systems. > Packages may include support for init systems like systemd service > units in addition to init scripts. Current policy makes it an RC bug > to include a service unit without an init script. > > Policy editors are requested to amend policy; including a service unit > without an init script is appropriate for a non-maintainer upload but > should no longer be an RC bug. If this choice wins, then why should it not be an RC bug to not have an init script? That doesn't seem to make sense. > Policy editors are requested to > consider whether there are cases where removing an init script that > used to be provided should be RC because it would break a system on > upgrade. > > Once the community of users of an alternate init system have said that >
Re: Init Systems GR Timeline
On Fri, Nov 08, 2019 at 06:46:53PM -0500, Sam Hartman wrote: > I think you may be mishearing what I'm proposing for a timeline. [...] thanks for clarifying, Sam, much appreciated. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
