Aigars Mahinovs wrote: > On 24 October 2014 17:14, Josh Triplett <j...@joshtriplett.org> wrote: > >> The key difference is that until this year all packages worked on all > >> init systems (as in you could start any service or application with > >> any init system as PID 1, even with "init=/bin/sh"). > > > > Until recently, it was a painful endeavor to be the upstream of a daemon > > package, because init scripts were not portable between Linux > > distributions; each distribution tended to have to write their own. > > systemd actually viewed that as a *problem*, and *fixed* it; it *is* > > fairly reasonable now to ship a .service or .socket or other unit file > > upstream and expect distributions to not need to change it. > > That is *not* what the discussion is about. It is *not* about init > scripts. Forget about init scripts. Imagine booting up a system with > "init=/bin/sh" - it should be possible to run a command to start your > service from there (without any init system at all). If you depend on > other services, then those should be startable with simple commands > too. If that is possible, then all is fine.
"exec /lib/systemd/systemd". ;) More seriously, no, your expectations are no longer realistic or reasonable. It is already not possible *today* to run "simple commands" and end up with a working system; many services depend on other running services, and the thing gluing them together is an init system. You cannot, for instance, just run "foo-daemon" or even "/etc/init.d/foo-daemon start" for an arbitrary foo, not least of which because that won't enforce the starting of things foo depends on. In turn, those dependencies may include DBus services, or udev-managed devices and device events. You can't run DBus services without DBus (though systemd is actually working to fix that), and you can't generate udev events without udev. Without such mechanisms, software may well fail to launch or operate correctly. The world is more complex than your model, and has been for far longer than systemd has existed. Your init=/bin/sh system may well depend on an initramfs to successfully boot. You may not be able to type on your keyboard without running a daemon (e.g. for a Bluetooth keyboard). You might not even have a text console without running a daemon. Those daemons themselves may depend on other services. It's perfectly reasonable, for instance, for a daemon to expect to be run as a non-root user, and be handed a low-numbered socket that it could not itself open. It's not reasonable to require every daemon to reimplement that code itself, with all associated security requirements. It's also reasonable for you to reimplement that functionality in some other system, and convince upstreams to use your version instead. For instance, you might adapt a piece of software to work with inetd rather than a .socket file. > If systemd adds socket activation and you daemon uses it it is fine > for the start up of that daemon to use socket activation. If a user > is running another init system it is fine for socket activation not to > work, but a problem would be for your daemon to crash or hang on > startup because of this. Expect an increasing number of new upstream daemons to lack any code to daemonize themselves, or to start as root and drop privileges, when a perfectly reasonable and better-audited implementation already exists to launch the daemon as non-root with no forking. And that's two of several hundred features. You cannot expect all upstreams to *duplicate* functionality that already exists, nor to maintain such duplication indefinitely. > > In practice, demanding that packages work with all init systems, or even > > with *two* init systems, demands that they support the > > least-common-denominator of functionality provided by those init > > systems. That effectively makes any new feature added to an init system > > useless until duplicated. > > Yes - the demand is to make sure that the least-common-denominator > does actually minimally work. I appreciate that you actually acknowledge this rather than avoiding it, but nonetheless, no, arrogant demand refused; systemd, like the Linux kernel and many other pieces of software, provides useful functionality that other implementations do not have. Ask others nicely with convincing arguments and see if they'll do the work for you (many seem willing to), or do it yourself, or create other upstream software with different requirements that does not need systemd and package that software. > You may use the advanced features, if they are available, but can't > just assume that they will be. On the other hand it is fine to not > provide some functionality if the advanced init system features are > not available. Consider how ludicrous this would sound about any other software: "You may use the Linux kernel, if it's available, but you can't just assume that it will be. On the other hand, it is fine to not provide some functionality if Linux is not available." "You may use glibc, if it's available, but you can't just assume that it will be. On the other hand, it is fine to not provide some functionality if glibc is not available." "You may use the X Window System, if it's available, but you can't just assume that it will be. On the other hand, it is fine to not provide some functionality if X is not available." "You may use GCC, if it's available, but you can't just assume that it will be. On the other hand, it is fine to not provide some functionality if GCC is not available." Now, as a wishlist bug, sure, you could request fallbacks; some software may implement them. Currently, some software in Debian has done so for various dependencies. Huge parts of Debian, however, have hard dependencies on Linux, glibc, X, and GCC, and those dependencies are not in any way unreasonable. > > And in many cases, the systemd-invented services and features fill a gap > > for which no previously implementation existed, so "used to work before" > > is quite inaccurate. Not all features are optional; not every feature > > needs fallback code to cope with its lack. Doubly so if such fallback > > code does not already exist. > > If some software used to work before systemd Bad assumption. All useful software was not written before systemd, nor did all software development halt when systemd was created. Software develops new functionality. > there is no technical > excuse for it not working with other init systems after systemd > integration. There most certainly are good technical reasons, and you should already be well aware of that. We create libraries and otherwise factor out common code for a reason, and it's often to *throw away* duplicate implementations in favor of a one or more well-maintained common implementations. Now, there may be *political* reasons for software to work with other init systems. But "I don't like systemd" is not in any way a technical argument. If you have any technical arguments for not running systemd, report them as bugs on systemd (upstream, please) so they can be fixed. > If there was no socket activation before, it can not be > such an essential feature that you simply can not function without it. Notice the vast set of software libraries in Debian with library minor version numbers larger than 0, suggesting that they've added functionality that old versions do not have, and enforcing that software using those features will not run with old versions of the library. Also notice the large number of new libraries that appear, and software that depends on those libraries, which will not run without the presence of those libraries. New features arise every day that other software will wish to depend on. If you don't want those features used, create even better ones to use instead. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024161836.GA19079@thin
