Re: [TECH TOPIC] Kernel documentation - update and future directions

[Jonathan Corbet <corbet@lwn.net>]

Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:

> On Wed, Sep 03, 2025 at 05:11:12PM +0200, Johannes Berg wrote:
>> On Wed, 2025-09-03 at 16:57 +0200, Mauro Carvalho Chehab wrote:
>> > There are actually 3 different issues that depend on python version:
>> > 
>> > 1. sphinx-pre-install:
>> > 
>> >     This used to be a Perl script. The goal is to check if sphinx-build
>> >     is installed and works, and identify missing dependencies.
>> > 
>> >     The problem is: if one installs python3xx-Sphinx, instead of
>> >     python3-Sphinx, the script will fail, except if it first switches
>> >     to python3.xx;
>> 
>> So let it fail. Fail is fine, at least it's a clear signal. The python3-
>> Spinx package will anyway be a sort of meta-package that's basically
>> empty and depends on a specific version.
>
> No, that's not the case. On Leap, python3-Sphinx uses python 3.6 and has
> Sphinx version 2.3.x, which is too old.

That's Leap 15, presumably?  Given that 16 is due Real Soon Now, perhaps
before any kernel with these changes is released, do we need to concern
ourselves with that?

> True, but at least one of the major LTS distros don't have it(*).
>
> We can review it after Leap is replaced for the next openSUSE release.
>
> (*) also, RHEL8 (and its derivated releases) suffer the same issues
>      and they aren't EOL yet.
>
> For most of us, I doubt the fallback logic would ever be used.

CentOS 8 stream went EOL over a year ago.  How many people have systems
stuck on RHEL 8 and are using them to do docs builds?

> When it becomes painful, we can drop it.
>
> Anyway, I'll let it for Jon to decide.

I still really don't think that adding that stuff is a good idea; our
scripts should behave the way people expect them to and not go rooting
around for alternative interpreters to feed themselves to.  I appreciate
that you want to make things Just Work for people, that is a great goal,
but this seems a step too far.

Thanks,

jon