First of all, Josh, thank you for the long and reasoned replies. I do
hope this back-and-forth is useful for others as well in the context
of this decision, that is why I am still keeping the debian-vote list
in the CC.
On 24 October 2014 19:18, Josh Triplett <j...@joshtriplett.org> wrote:
> Aigars Mahinovs wrote:
>> 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.
>
> 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.
I am assuming that the person running the commands know about the
dependencies in the services and starts them up manually and in the
right order. Init system does *not* glue services together it only
starts them in right order with right options - after that init system
does not participate in the inter-process communication.
> 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.
That is what tools like start-stop-daemon or daemontools are for.
There is no need to reinvent things for every daemon and there is no
need to hardlock them into the init system too.
>> 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.
I can see how it is beneficial to use something like that by default,
but if you remove, for example, the command line options for
specifying port to bind to, then you loose all kinds of non-default
functionality, like the ability to run the same or a different version
of a service as a one-shot on high port by a regular user, to start up
a debug version locally, .... Sure it is easier to write a daemon that
can only be started as a systemd service, but along with loosing
support for all other init systems you also loose a lot of
flexibility.
>> 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."
[snip]
> 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.
Actually, we kind of do that - such things are detected by configure
scripts, for example. But all your examples (except GCC) are systems
that applications have always been calling. Applications have never
been calling init system before. Try the same assumption with: bash,
Metacity, gnome-shell. "When you application is started, it might be
started by gnome-shell, in that case you may give gnome-shell an
indication about your startup animation, but you may be started by
something else, in that case you should still start, but it is fine
not to provide the correct startup animation."
I do like the kernel and architectures analogies. We don't have a
policy requiring software to work on all kernels/architectures. I
believe that this situation is different because of the difference in
starting conditions - imagine if in previous Debian release *all*
software worked on all architectures, including kFreeBSD and Hurd and
then TC declared that Linux/amd64 is the new default architecture
(like what architecture install image shows up on the homepage) which
is quickly followed by people introducing new versions of important
software that is "cleaned up and streamlined" by removing all that
pesky support for non-default architectures. Sure it is much easier to
support software that is written just for one kernel and one
architecture. Sure, you can say that "patches for other arches and
kernels are welcome". But if you "clean up" all the automake away and
rewrite the app to use cgroups ... patches are not going to be easy to
come up with. And people in other architectures and kernels might be
reasonably annoyed. Argumentation that Linux/amd64 should be
technically fine for everyone, everywhere would not be too welcomed
either.
>> 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.
I am all for common code and libraries. What I am *not* for is putting
that common code into an *exclusive* system component. We have
libraries and file system for that. A service using start-stop-daemon
to daemonise itself does not prevent another service from using
daemontools to do the same thing, but slightly differently. There can
be *only one* init system active. There can be *any* number of
libraries and daemon helper tools active at any point. Having the
ability to do only a small piece of the puzzle allows easier
development of such tools, because tools don't have to be best at
*everything* before it can be considered, it might just be best at
starting web servers and still be very, very useful.
--
Best regards,
Aigars Mahinovs mailto:aigar...@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
--
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/cabpywdu97pw+vuopomqu5gnkze8b2rsd6j7s2sduvv9ebuq...@mail.gmail.com
