docs,man: more SysV compat removal notes

diff --git a/docs/INCOMPATIBILITIES.md b/docs/INCOMPATIBILITIES.md
index 784f3a2c026b8de0c902890d44e7a3b504c8d910..4695f0262f1f05a2791e5fda1b6f57cfc0f183bf 100644 (file)
--- a/docs/INCOMPATIBILITIES.md
+++ b/docs/INCOMPATIBILITIES.md
@@ -7,6 +7,10 @@ SPDX-License-Identifier: LGPL-2.1-or-later
 
 # Compatibility with SysV
 
+Since systemd v260, support for SysV functionalities has been removed. The documentation below is preserved for historical references only.
+
+## Pre v260 state
+
 systemd provides a fair degree of compatibility with the behavior exposed by the SysV init system as implemented by many distributions.
 Compatibility is provided both for the user experience and the SysV scripting APIs.
 However, there are some areas where compatibility is limited due to technical reasons or design decisions of systemd and the distributions.
@@ -33,5 +37,3 @@ Many of the incompatibilities are specific to distribution-specific extensions o
 * systemd's handling of the existing "nofail" mount option in /etc/fstab is stricter than it used to be on some sysvinit distributions: mount points that fail and are not listed as "nofail" will cause the boot to be stopped, for security reasons, as we should not permit unprivileged code to run without everything listed — and not expressly exempted through "nofail" — being around. Hence, please mark all mounts where booting shall proceed regardless whether they succeeded or not with "nofail"
 * Some SysV systems support an "rc.local" script that is supposed to be called "last" during boot. In systemd, the script is supported, but the semantics are less strict, as there is simply no concept of "last service", as the boot process is event- and request-based, parallelized and compositive. In general, it's a good idea to write proper unit files with properly defined dependencies, and avoid making use of rc.local.
 * systemd assumes that the UID boundary between system and regular users is a choice the distribution makes, and not the administrator. Hence it expects this setting as compile-time option to be picked by the distribution. It will _not_ check /etc/login.defs during runtime.
-
-Note that there are some areas where systemd currently provides a certain amount of compatibility where we expect this compatibility to be removed eventually.

diff --git a/man/daemon.xml b/man/daemon.xml
index 1d9b937b2f650548771aeb620dc2f7f8d57e9adf..b51cbe2a33e2d993e0a9e9a19cf17d5b00114f84 100644 (file)
--- a/man/daemon.xml
+++ b/man/daemon.xml
@@ -284,11 +284,11 @@
       <para>Old-style daemons are usually activated exclusively on boot (and manually by the administrator)
       via SysV init scripts, as detailed in the <ulink
       url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB
-      Linux Standard Base Core Specification</ulink>. This method of activation is supported ubiquitously on
-      Linux init systems, both old-style and new-style systems. Among other issues, SysV init scripts have
-      the disadvantage of involving shell scripts in the boot process. New-style init systems generally use
-      updated versions of activation, both during boot-up and during runtime and using more minimal service
-      description files.</para>
+      Linux Standard Base Core Specification</ulink>. Among other issues, SysV init scripts have
+      the disadvantage of involving shell scripts in the boot process. Support for init scripts has been
+      phased out in modern Linux init systems, and should not be relied upon. New-style init systems
+      generally use updated versions of activation, both during boot-up and during runtime and using
+      more minimal service description files.</para>
 
       <para>In systemd, if the developer or administrator wants to
       make sure that a service or other unit is activated