Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

tags -1 moreinfo

Bug #977358 [release-notes] release-notes: document how to make the rescue mode usable if no root password is set (buster)
Added tag(s) moreinfo.

--
977358: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977358
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems

Paul Gevers

2021-03-18 11:00:02 UTC

Control: tags -1 moreinfo

On Mon, 14 Dec 2020 13:12:59 +0200 Andrei POPESCU

Post by Andrei POPESCU
Some text based on below would make sense for the Release Notes for
buster. If agreed I'll try to come up with a wording.

Sure. Does this also apply for bullseye, or is the issue fix somehow?

This is a pretty strong (and harsh!) statement. Care to expand on the
reasons?

It prevents access to single-user mode. The fact that Debian (and
these others?) still puts a single-user mode entry into the GRUB menu,
knowing that it won't work, is just adding insult to injury.

A web search found #802211[1].
For systemd >= 240 (buster[2]) run as root
systemctl edit rescue.service
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1
(see /usr/share/doc/systemd/ENVIRONMENT.md.gz)
The 'rescue.service' is started by systemd in case it detects 'single'
on the kernel command line (see systemd(1)).
You might want to do the same for 'emergency.service' as well (or
instead), since this service is started *automatically* in case of
certain errors (see systemd.special(7)) or if you add 'emergency' to the
kernel command line (e.g. if you can't fix your system via the 'rescue'
service).
An untested patch to the Debian Installer exists to add both snippets if
the user chooses to leave the root password blank.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
[2] see the bug for another snippet that should work for squeeze or
earlier.

Paul

Andrei POPESCU

2021-03-21 07:40:01 UTC

Post by Paul Gevers
Control: tags -1 moreinfo
On Mon, 14 Dec 2020 13:12:59 +0200 Andrei POPESCU

Post by Andrei POPESCU
Some text based on below would make sense for the Release Notes for
buster. If agreed I'll try to come up with a wording.

Sure. Does this also apply for bullseye, or is the issue fix somehow?

Only if D-I was fixed in the meantime.

Post by Andrei POPESCU
An untested patch to the Debian Installer exists to add both snippets if
the user chooses to leave the root password blank.

It will be a while until I can test this, maybe someone else on d-u can
do so faster (will ask in a separate message).

Kind regards,
Andrei

--
http://wiki.debian.org/FAQsFromDebianUser

Paul Gevers

2021-04-06 20:00:02 UTC

Hi Andrei,

Post by Paul Gevers
Control: tags -1 moreinfo
On Mon, 14 Dec 2020 13:12:59 +0200 Andrei POPESCU

Post by Andrei POPESCU
Some text based on below would make sense for the Release Notes for
buster. If agreed I'll try to come up with a wording.

Sure. Does this also apply for bullseye, or is the issue fix somehow?

Only if D-I was fixed in the meantime.

Post by Andrei POPESCU
An untested patch to the Debian Installer exists to add both snippets if
the user chooses to leave the root password blank.

It will be a while until I can test this, maybe someone else on d-u can
do so faster (will ask in a separate message).

Did you already have inspiration for some text? Apparently it still
applies to bullseye and its release is drawing nearer.

Paul

Andrei POPESCU

2021-04-10 06:20:03 UTC

Post by Paul Gevers
Hi Andrei,

Post by Paul Gevers
Control: tags -1 moreinfo
On Mon, 14 Dec 2020 13:12:59 +0200 Andrei POPESCU

Post by Andrei POPESCU
Some text based on below would make sense for the Release Notes for
buster. If agreed I'll try to come up with a wording.

Sure. Does this also apply for bullseye, or is the issue fix somehow?

Only if D-I was fixed in the meantime.

Post by Andrei POPESCU
An untested patch to the Debian Installer exists to add both snippets

Post by Andrei POPESCU
the user chooses to leave the root password blank.

It will be a while until I can test this, maybe someone else on d-u can
do so faster (will ask in a separate message).

Did you already have inspiration for some text? Apparently it still
applies to bullseye and its release is drawing nearer.

Ok, here is something, just to get the discussion started:

The `rescue` boot option is unusable without a root password.

If a password for the `root` account is not set the system will
still ask for the root password if booted with the `rescue` option,
effectively making the rescue mode unusable. In order to avoid this
it is possible to boot using the kernel parameter
`init=/sbin/sulogin --force`.

To configure pkg:systemd to always to do the equivalent of this on
selecting the `rescue` option add `SYSTEMD_SULOGIN_FORCE=1` to the
Environment of the rescue.service unit (see
file:/usr/share/doc/systemd/ENVIRONMENT.md.gz). The `rescue.service`
unit is started by pkg:systemd in case it detects `single` in the
kernel command line (see man:systemd).

It might be useful to do the same for the `emergency.service` unit
(or instead) which is started ''automatically'' in case of certain
errors (see man:systemd.special), or if `emergency` is added to the
kernel command line (e.g. in case the system can't be recovered by
using the `rescue` mode).

For background and a discussion on the security implications see
bts:802211.

The pseudo-markup should be obvious. I'll try to come up with a patch
later, unless Someone Else (TM) beats me to it ;)

Kind regards,
Andrei

--
http://wiki.debian.org/FAQsFromDebianUser

Justin B Rye

2021-04-10 10:00:02 UTC

Thanks! My suggestions below still need some work, but I'll call this

Post by Andrei POPESCU
The `rescue` boot option is unusable without a root password.
If a password for the `root` account is not set the system will
still ask for the root password if booted with the `rescue` option,
effectively making the rescue mode unusable. In order to avoid this
it is possible to boot using the kernel parameter
`init=/sbin/sulogin --force`.

Simplifying:

<title>
The <literal>rescue</literal> boot option is unusable without a root password
</title>
<para>
Booting with the <literal>rescue</literal> option always requires
the root password. If one has not been set, this makes the rescue
mode effectively unusable. However it is still possible to boot
using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
</para>

(I don't think "root" needs special markup; "rescue" only needs it
when we're talking about an untranslatable literal string).

(Should there be some hint here at the fact that this has happened
because we've switched to an implementation of sulogin without the
slightly dodgy Debian-specific patches?)

Post by Andrei POPESCU
To configure pkg:systemd to always to do the equivalent of this on

^^^ ^^ ^^
When we're talking about machines booting with systemd-sysv, we should
avoid mentioning <systemitem role="package">systemd</systemitem>
(which is a pain to type anyway).

The "to" might go in either position, but not both. Here perhaps we
might be better off saying

To configure systemd to do the equivalent of this whenever the
<literal>rescue</literal> option is used,

Post by Andrei POPESCU
selecting the `rescue` option add `SYSTEMD_SULOGIN_FORCE=1` to the
Environment of the rescue.service unit (see
file:/usr/share/doc/systemd/ENVIRONMENT.md.gz). The `rescue.service`

At least this information is already on my system before the
dist-upgrade.

Post by Andrei POPESCU
unit is started by pkg:systemd in case it detects `single` in the

^^^^^^^

Post by Andrei POPESCU
kernel command line (see man:systemd).

Bad use of "in case" - most English-speakers interpret "in case of" as
"unconditionally, to avert the danger of".

systemd(1) defines "single" and "rescue" (and "1"!) as aliases of
"systemd.unit=rescue.target", so maybe we can make that clearer
earlier.

<para>
To configure systemd to do the equivalent of this whenever it
boots into rescue mode (also known as single mode - see <ulink
url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
add <literal>SYSTEMD_SULOGIN_FORCE=1</literal> to the
Environment of the <literal>rescue.service</literal> unit (see
<filename>/usr/share/doc/systemd/ENVIRONMENT.md.gz</filename>).
</para>

Unfortunately we also need readers to know
* how to add things to a systemd unit (we don't want people editing
/lib/systemd/system/rescue.service and losing it in an upgrade)
* how much of the rest of the file they should copy (as little as
possible, I think, but how much is that?)
* how the syntax for multiple items in an Environment= line works

This probably needs an external link, but I'm not optimistic we'll
find one. Maybe this is another case where we'll need a dedicated
page on wiki.debian.org.

(And why *is* the systemd man page in section 1, anyway? Shouldn't it
be in section 8, like systemv init used to be?)

Post by Andrei POPESCU
It might be useful to do the same for the `emergency.service` unit
(or instead) which is started ''automatically'' in case of certain

^^^^^^^^^^ ^^^^^^^^^^

Post by Andrei POPESCU
errors (see man:systemd.special), or if `emergency` is added to the
kernel command line (e.g. in case the system can't be recovered by

^^^^^^^

Post by Andrei POPESCU
using the `rescue` mode).

"The same or instead" needs to be reorganised as "as well or instead".

One of those "in case"s almost works.

I'm not sure what markup you mean for ''automatically''.

<para>
It might be useful to do this for the <literal>emergency.service</literal>
unit (as well or instead), which is started automatically in the case
of certain errors (see <ulink
url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
or if <literal>emergency</literal> is added to the kernel command line
(e.g. if the system can't be recovered by using the rescue mode).
</para>

(Why *did* setting these systems up with passwords in the first place
go out of fashion?)

Post by Andrei POPESCU
For background and a discussion on the security implications see
bts:802211.

I forget if we've got special markup for this or whether we just say

<para>
For background and a discussion on the security implications see
<ulink url="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211">bug
#802211</ulink>.
</para>

Or even delegate it to the wiki link. Oh well, buster needed two
last-minute wiki pages for complicated issues, so if bullseye only
needs one for this we'll still be improving...

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Andrei POPESCU

2021-04-10 15:10:01 UTC

Post by Justin B Rye
Thanks! My suggestions below still need some work, but I'll call this

<title>
The <literal>rescue</literal> boot option is unusable without a root password
</title>
<para>
Booting with the <literal>rescue</literal> option always requires
the root password. If one has not been set, this makes the rescue
mode effectively unusable. However it is still possible to boot
using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
</para>
(I don't think "root" needs special markup; "rescue" only needs it
when we're talking about an untranslatable literal string).

Post by Justin B Rye
(Should there be some hint here at the fact that this has happened
because we've switched to an implementation of sulogin without the
slightly dodgy Debian-specific patches?)

This is explained in the bug report for who cares to investigate, in my
opinion it's not needed in the Release Notes.

Post by Andrei POPESCU
To configure pkg:systemd to always to do the equivalent of this on

^^^ ^^ ^^
When we're talking about machines booting with systemd-sysv, we should
avoid mentioning <systemitem role="package">systemd</systemitem>
(which is a pain to type anyway).
The "to" might go in either position, but not both. Here perhaps we
might be better off saying

It's a consequence of some rewrite :)

Post by Justin B Rye
To configure systemd to do the equivalent of this whenever the
<literal>rescue</literal> option is used,

At least this information is already on my system before the
dist-upgrade.

Post by Andrei POPESCU
unit is started by pkg:systemd in case it detects `single` in the

^^^^^^^

Post by Andrei POPESCU
kernel command line (see man:systemd).

Bad use of "in case" - most English-speakers interpret "in case of" as
"unconditionally, to avert the danger of".

I'll have to trust you on this (and make a mental note about it).

Post by Justin B Rye
systemd(1) defines "single" and "rescue" (and "1"!) as aliases of
"systemd.unit=rescue.target", so maybe we can make that clearer
earlier.
<para>
To configure systemd to do the equivalent of this whenever it
boots into rescue mode (also known as single mode - see <ulink
url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
add <literal>SYSTEMD_SULOGIN_FORCE=1</literal> to the
Environment of the <literal>rescue.service</literal> unit (see
<filename>/usr/share/doc/systemd/ENVIRONMENT.md.gz</filename>).
</para>
Unfortunately we also need readers to know
* how to add things to a systemd unit (we don't want people editing
/lib/systemd/system/rescue.service and losing it in an upgrade)
* how much of the rest of the file they should copy (as little as
possible, I think, but how much is that?)
* how the syntax for multiple items in an Environment= line works
This probably needs an external link, but I'm not optimistic we'll
find one. Maybe this is another case where we'll need a dedicated
page on wiki.debian.org.

As you probably know, it's as simple as:

systemctl edit rescue.service

and add

[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1

It seemed a little bit much to add this as well, but I'm fine either
way.

Post by Justin B Rye
(And why *is* the systemd man page in section 1, anyway? Shouldn't it
be in section 8, like systemv init used to be?)

Post by Andrei POPESCU
It might be useful to do the same for the `emergency.service` unit
(or instead) which is started ''automatically'' in case of certain

^^^^^^^^^^ ^^^^^^^^^^

Post by Andrei POPESCU
errors (see man:systemd.special), or if `emergency` is added to the
kernel command line (e.g. in case the system can't be recovered by

^^^^^^^

Post by Andrei POPESCU
using the `rescue` mode).

"The same or instead" needs to be reorganised as "as well or instead".
One of those "in case"s almost works.
I'm not sure what markup you mean for ''automatically''.

Some form of emphasis, to draw attention to the fact that users might
find themselves stuck at the emergency console.

Post by Justin B Rye
<para>
It might be useful to do this for the <literal>emergency.service</literal>
unit (as well or instead), which is started automatically in the case
of certain errors (see <ulink
url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
or if <literal>emergency</literal> is added to the kernel command line
(e.g. if the system can't be recovered by using the rescue mode).
</para>
(Why *did* setting these systems up with passwords in the first place
go out of fashion?)

For me it was a natural consequence of using sudo exclusively ;)

Post by Andrei POPESCU
For background and a discussion on the security implications see
bts:802211.

I forget if we've got special markup for this or whether we just say

All entities are in a dedicated file (I don't have a checkout handy to
look it up).

Post by Justin B Rye
<para>
For background and a discussion on the security implications see
<ulink url="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211">bug
#802211</ulink>.
</para>
Or even delegate it to the wiki link. Oh well, buster needed two
last-minute wiki pages for complicated issues, so if bullseye only
needs one for this we'll still be improving...

This is actually applicable for buster as well, unfortunately it wasn't
fixed for bullseye (patch for d-i was still pending last time I
checked).

Kind regards,
Andrei

--
http://wiki.debian.org/FAQsFromDebianUser

Justin B Rye

2021-04-10 17:50:01 UTC

Post by Justin B Rye
(Should there be some hint here at the fact that this has happened
because we've switched to an implementation of sulogin without the
slightly dodgy Debian-specific patches?)

This is explained in the bug report for who cares to investigate, in my
opinion it's not needed in the Release Notes.

This was mostly a note to myself in the hope that I'd find a way of
leading into it that accentuated the positive - after all, this is
just a side-effect of improvements elsewhere. But when we're this
late documenting it, it's a non-starter.

[...]

Post by Justin B Rye
This probably needs an external link, but I'm not optimistic we'll
find one. Maybe this is another case where we'll need a dedicated
page on wiki.debian.org.

systemctl edit rescue.service
and add
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1

Well, I know that now, because I've been looking it up, but I wasn't
sure as I wrote that, and it's not as easy to pull the details
together as it should be. Still, at least it doesn't need the usual
reminders to run daemon-reload or reboot. But instead of telling
people all about where to hunt for the information it might be quicker
in this case just to put the answer in the text!

<title>
The <literal>rescue</literal> boot option is unusable without a root password
</title>
<para>
Booting with the <literal>rescue</literal> option always requires
the root password. If one has not been set, this makes the rescue
mode effectively unusable. However it is still possible to boot
using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
</para>
<para>
To configure systemd to do the equivalent of this whenever it boots
into rescue mode (also known as single mode: see <ulink
url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
run <command>sudo systemctl edit rescue.service</command> and create
a file saying just:
</para>
<screen>
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1
</screen>
<para>
It might also (or instead) be useful to do this for the
<literal>emergency.service</literal> unit, which is started
<emphasis>automatically</emphasis> in the case of certain
errors (see <ulink
url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
or if <literal>emergency</literal> is added to the kernel
command line (e.g. if the system can't be recovered by using
the rescue mode).
</para>

[...]

Post by Justin B Rye
(Why *did* setting these systems up with passwords in the first place
go out of fashion?)

For me it was a natural consequence of using sudo exclusively ;)

Ah, well, it's the old slogan - "Debian: giving you the power to shoot
yourself in each toe individually."

Post by Andrei POPESCU
For background and a discussion on the security implications see
bts:802211.

I forget if we've got special markup for this or whether we just say

All entities are in a dedicated file (I don't have a checkout handy to
look it up).

I can't see the definition, but judging by old .po files we want

<para>
For background and a discussion on the security implications see
<ulink url="&url-bts;/802211">#802211</ulink>.
</para>

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Paul Gevers

2021-04-12 20:10:02 UTC

Hi Justin, Andrei,

Thanks for the proposed text below. I struggle a bit with where to place
it. What do you suggest? It's not really an upgrading issue, is it?

Paul
@Andrei, I guess I should put it in the equivalent place in the buster
release notes too, right, after fixing suite names in the text?

Post by Justin B Rye
(Should there be some hint here at the fact that this has happened
because we've switched to an implementation of sulogin without the
slightly dodgy Debian-specific patches?)

This is explained in the bug report for who cares to investigate, in my
opinion it's not needed in the Release Notes.

Post by Justin B Rye
This probably needs an external link, but I'm not optimistic we'll
find one. Maybe this is another case where we'll need a dedicated
page on wiki.debian.org.

systemctl edit rescue.service
and add
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1

Well, I know that now, because I've been looking it up, but I wasn't
sure as I wrote that, and it's not as easy to pull the details
together as it should be. Still, at least it doesn't need the usual
reminders to run daemon-reload or reboot. But instead of telling
people all about where to hunt for the information it might be quicker
in this case just to put the answer in the text!
<title>
The <literal>rescue</literal> boot option is unusable without a root password
</title>
<para>
Booting with the <literal>rescue</literal> option always requires
the root password. If one has not been set, this makes the rescue
mode effectively unusable. However it is still possible to boot
using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
</para>
<para>
To configure systemd to do the equivalent of this whenever it boots
into rescue mode (also known as single mode: see <ulink
url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
run <command>sudo systemctl edit rescue.service</command> and create
</para>
<screen>
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1
</screen>
<para>
It might also (or instead) be useful to do this for the
<literal>emergency.service</literal> unit, which is started
<emphasis>automatically</emphasis> in the case of certain
errors (see <ulink
url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
or if <literal>emergency</literal> is added to the kernel
command line (e.g. if the system can't be recovered by using
the rescue mode).
</para>
[...]

Post by Justin B Rye
(Why *did* setting these systems up with passwords in the first place
go out of fashion?)

For me it was a natural consequence of using sudo exclusively ;)

Ah, well, it's the old slogan - "Debian: giving you the power to shoot
yourself in each toe individually."

Post by Andrei POPESCU
For background and a discussion on the security implications see
bts:802211.

I forget if we've got special markup for this or whether we just say

All entities are in a dedicated file (I don't have a checkout handy to
look it up).

I can't see the definition, but judging by old .po files we want
<para>
For background and a discussion on the security implications see
<ulink url="&url-bts;/802211">#802211</ulink>.
</para>

Justin B Rye

2021-04-13 09:20:02 UTC

Post by Paul Gevers
Hi Justin, Andrei,
Thanks for the proposed text below. I struggle a bit with where to place
it. What do you suggest? It's not really an upgrading issue, is it?

Maybe at the end of "issues", next to the similarly chronic issue of
GNOME mouseless a11y? That's under "package-specific-issues" at
present, mislabelled as a case where the package might not upgrade
smoothly; we don't really have any known cases of that to list, so
maybe we ought to reorganise the subsections a bit. I would have
hoped we could arrange things so that the bookworm deprecations
subsection is at the very end, and whether we do that or not we might
want the "limited-security-support" bit to be alongside the a11y and
rescue.service bits in a "chronic-problems" section (but don't call it
that).

Post by Justin B Rye
<title>
The <literal>rescue</literal> boot option is unusable without a root password
</title>
<para>

If this goes in a list that's organised in terms of packages then it
needs to give more of a hint about where the problem originated:

^With the implementation of <literal>sulogin</literal> now used,

Post by Justin B Rye
Booting with the <literal>rescue</literal> option always requires
the root password. If one has not been set, this makes the rescue
mode effectively unusable. However it is still possible to boot
using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
</para>
<para>
To configure systemd to do the equivalent of this whenever it boots
into rescue mode (also known as single mode: see <ulink
url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
run <command>sudo systemctl edit rescue.service</command> and create
</para>
<screen>
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1
</screen>
<para>
It might also (or instead) be useful to do this for the
<literal>emergency.service</literal> unit, which is started
<emphasis>automatically</emphasis> in the case of certain
errors (see <ulink
url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
or if <literal>emergency</literal> is added to the kernel
command line (e.g. if the system can't be recovered by using
the rescue mode).
</para>

Looking at that paragraph again, the man page is good enough to make
me consider shortening it to

The same applies to the <literal>emergency.service</literal>
unit, for booting into emergency mode; see <ulink
url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>.

Post by Justin B Rye
<para>
For background and a discussion on the security implications see
<ulink url="&url-bts;/802211">#802211</ulink>.

^bug

Post by Justin B Rye
</para>

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Andrei POPESCU

2021-04-13 09:40:01 UTC

Post by Justin B Rye
If this goes in a list that's organised in terms of packages then it
^With the implementation of <literal>sulogin</literal> now used,

Or maybe

/now used/used since buster?

Otherwise Justin's suggestions are fine for me.

Kind regards,
Andrei

--
http://wiki.debian.org/FAQsFromDebianUser

Paul Gevers

2021-04-16 20:10:02 UTC

Hi Justin,

[...] "package-specific-issues" at
present, mislabelled as a case where the package might not upgrade
smoothly; we don't really have any known cases of that to list, so
maybe we ought to reorganise the subsections a bit. I would have
hoped we could arrange things so that the bookworm deprecations
subsection is at the very end, and whether we do that or not we might
want the "limited-security-support" bit to be alongside the a11y and
rescue.service bits in a "chronic-problems" section (but don't call it
that).

How about (dropping the package specific section, and just merge it into
upgrade items):
5.1. Upgrade specific items for bullseye
5.2. Items not limited to the upgrade process
* Limitations in security support
* Gnome accessibility issue
* password-less rescue mode
5.3. Obsolescence and deprecation
* Noteworthy obsolete packages
* Deprecated components for bullseye

Now I'm going over it, the Python2 is probably also not in the right
section. I think it warrants to be mentioned under "Noteworthy obsolete
packages" (section of 5.1) as the Python2 deprecation has resulted in *a
lot* of Python2 packages to have been removed.

Paul
PS: on the one hand it feels more natural to have deprecate before
obsolete, but on the other hand I guess it's more important to learn
about obsolete packages, so that goes first?

Justin B Rye

2021-04-17 05:10:02 UTC

Post by Paul Gevers
How about (dropping the package specific section, and just merge it into
5.1. Upgrade specific items for bullseye
5.2. Items not limited to the upgrade process
* Limitations in security support
* Gnome accessibility issue
* password-less rescue mode
5.3. Obsolescence and deprecation
* Noteworthy obsolete packages
* Deprecated components for bullseye

That's just about what I was thinking, if I'd taken the trouble to
look up the section numbers.

Post by Paul Gevers
Now I'm going over it, the Python2 is probably also not in the right
section. I think it warrants to be mentioned under "Noteworthy obsolete
packages" (section of 5.1) as the Python2 deprecation has resulted in *a
lot* of Python2 packages to have been removed.

If we move it then it probably also needs... maybe just an extra line:

Python 2 is already beyond its End Of Life, and will receive no
security updates. It is not supported for running applications,
+ and packages relying on it have either been switched to Python 3 or removed.
However, Debian bullseye does still include a version of Python 2.7,

Post by Paul Gevers
Paul
PS: on the one hand it feels more natural to have deprecate before
obsolete, but on the other hand I guess it's more important to learn
about obsolete packages, so that goes first?

I like having "obsolete" first; maybe that's because I'm hoping to
get a py2less system this summer but I'm still treating the
deprecation of unmerged /usr as just a cloud on the horizon.

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Debian Bug Tracking System

2021-04-17 18:50:01 UTC