]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
os-release: define SUPPORT_END=
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Wed, 6 Jul 2022 15:19:27 +0000 (17:19 +0200)
committerYu Watanabe <watanabe.yu+github@gmail.com>
Wed, 6 Jul 2022 22:35:17 +0000 (07:35 +0900)
Fixes #21764.

I think is very simple, but flexible. The date may be set early, for distros
that have a fixed schedule, but it doesn't have to. So for example Debian could
push out an update that sets a few months before the release goes EOL. And
various tools, in particular graphical desktops, can start nagging people to
upgrade a few weeks before the date.

As discussed in the bug, we don't need granularity higher than a day. And this
means that we can use a simple human- and machine-readable format.
I was considering other names, e.g. something with "EOL", but I think that
"SUPPORT_END" is better because it doesn't imply that the machine will somehow
stop working. This is supposed to be an advisory, nothing more.

man/os-release.xml

index 90527228a2312543be3319e4aa0b841bcd1de799..fd98be5b7a38a2e25c68094077165a39eb6bf259 100644 (file)
           <literal>BUG_REPORT_URL="https://bugzilla.redhat.com/"</literal>.</para></listitem>
         </varlistentry>
 
+        <varlistentry>
+          <term><varname>SUPPORT_END=</varname></term>
+
+          <listitem><para>The date at which support for this version of the OS ends. (What exactly "lack of
+          support" means varies between vendors, but generally users should assume that updates, including
+          security fixes, will not be provided.) The value is a date in the format
+          <literal>YYYY-MM-DD</literal>, and specifies the last day on which support <emphasis>is</emphasis>
+          provided.</para></listitem>
+        </varlistentry>
+
         <varlistentry>
           <term><varname>LOGO=</varname></term>