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.
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.
> 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. 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.
> 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 there is no technical
excuse for it not working with other init systems after systemd
integration. If there was no socket activation before, it can not be
such an essential feature that you simply can not function without it.
--
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/cabpywdx5+-wupusr3-jux9fjpgiyztg8yhpweeh8wjyqc99...@mail.gmail.com
