From: Johannes Berg <johannes@sipsolutions.net>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Randy Dunlap <rdunlap@infradead.org>,
Jani Nikula <jani.nikula@intel.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Vegard Nossum <vegard.nossum@oracle.com>,
ksummit@lists.linux.dev,
Linux Documentation <linux-doc@vger.kernel.org>,
Akira Yokosawa <akiyks@gmail.com>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [TECH TOPIC] Kernel documentation - update and future directions
Date: Wed, 03 Sep 2025 17:11:12 +0200 [thread overview]
Message-ID: <874a85f2154d6b05635d856dcdd85d4715d19d3c.camel@sipsolutions.net> (raw)
In-Reply-To: <xxlm3ozmpel5iadhtambkzfx273oysjraffcizdmgexzhuqtwf@qxkwdvqmbadw>
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.
> 2. sphinx-build logic inside makefile, required for doc-specific targets:
>
> - If python < 3.7, doc builds fail;
Fine, python 3.7 is really old by now, if you actually have python3==3.7
you probably have other problems anyway. I don't think we need to
support that.
> - If python3xx-Sphinx is installed, build only works if started using
> the right python3.xx exec
Yeah, but again, we can require python3-sphinx here.
> Now, for (1) and (2), it should be possible to allow building docs even
> if the distro requires Python < 3.7, providing extra packages for newer
> Python, as almost all distros do. See, several distros require python
> on their minimal install images, because it can be using during package
> install. Removing the default python replacing by a new version may break
> the system, as the newer version may not be backward-compatible.
Umm, no? I'm not sure there's a need to cater to truly ancient software
in today's kernel build environment. Even debian *oldoldstable* has
python3==3.9:
https://packages.debian.org/bullseye/python3
> The best alternative seems to check if:
>
> - python version is bellow the minimal supported version;
> - there is a newer python binary at PATH;
> - check if sphinx-build runs with the newest version.
>
> If all those 3 conditions are met, build docs with a version that works,
> printing a message to tell the user what Python binary was used.
I still disagree. The only predictable thing is to use "python3" and
associated python3-xyz tools, and let things fail if those versions are
too old.
Picking a random different version that will depend on the kernel
version etc. is just going to introduce more moving parts and will
eventually be painful.
johannes
next prev parent reply other threads:[~2025-09-03 15:11 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87plcndkzs.fsf@trenco.lwn.net>
[not found] ` <20250828230104.GB26612@pendragon.ideasonboard.com>
[not found] ` <87wm6l0w2y.fsf@trenco.lwn.net>
2025-08-30 16:00 ` [TECH TOPIC] Kernel documentation - update and future directions Vegard Nossum
2025-08-30 22:23 ` Laurent Pinchart
2025-08-30 23:08 ` Jonathan Corbet
2025-08-31 14:03 ` Mauro Carvalho Chehab
2025-08-31 20:16 ` Jonathan Corbet
2025-09-01 6:17 ` Randy Dunlap
2025-09-01 19:27 ` Mauro Carvalho Chehab
2025-09-01 10:09 ` Jani Nikula
2025-09-01 16:51 ` Randy Dunlap
2025-09-01 17:52 ` Mark Brown
2025-09-01 18:15 ` Randy Dunlap
2025-09-01 18:20 ` Mark Brown
2025-09-01 18:25 ` Jonathan Corbet
2025-09-01 18:40 ` Mark Brown
2025-09-01 19:51 ` Jonathan Corbet
2025-09-01 22:52 ` Mauro Carvalho Chehab
2025-09-01 18:46 ` Mauro Carvalho Chehab
2025-09-01 18:52 ` Mark Brown
2025-09-01 22:56 ` Mauro Carvalho Chehab
2025-09-02 11:15 ` Mark Brown
2025-09-02 11:59 ` Mauro Carvalho Chehab
2025-09-02 12:14 ` Mauro Carvalho Chehab
2025-09-02 13:00 ` Mark Brown
2025-09-02 14:42 ` Mauro Carvalho Chehab
2025-09-02 15:15 ` Jonathan Corbet
2025-09-02 17:19 ` Mauro Carvalho Chehab
2025-09-02 18:52 ` Laurent Pinchart
2025-09-03 7:47 ` Jani Nikula
2025-09-03 10:04 ` Mauro Carvalho Chehab
2025-09-03 10:25 ` Jani Nikula
2025-09-02 18:58 ` Jonathan Corbet
2025-09-02 22:35 ` Mauro Carvalho Chehab
2025-09-03 6:29 ` Johannes Berg
2025-09-03 10:42 ` Mauro Carvalho Chehab
2025-09-03 10:45 ` Johannes Berg
2025-09-03 10:54 ` Johannes Berg
2025-09-03 14:57 ` Mauro Carvalho Chehab
2025-09-03 15:07 ` Laurent Pinchart
2025-09-03 15:17 ` Konstantin Ryabitsev
2025-09-03 15:22 ` Miguel Ojeda
2025-09-03 15:11 ` Johannes Berg [this message]
2025-09-03 15:25 ` Mauro Carvalho Chehab
2025-09-03 15:37 ` Jonathan Corbet
2025-09-03 15:52 ` Mauro Carvalho Chehab
2025-09-03 13:39 ` Mauro Carvalho Chehab
2025-09-03 13:51 ` Laurent Pinchart
2025-09-01 19:53 ` Jonathan Corbet
2025-09-01 23:15 ` Mauro Carvalho Chehab
2025-09-01 18:37 ` Mauro Carvalho Chehab
2025-09-01 19:05 ` Andrew Lunn
2025-09-01 19:17 ` Mark Brown
2025-09-02 10:42 ` Jani Nikula
2025-09-02 11:55 ` Mauro Carvalho Chehab
2025-09-02 12:07 ` Jani Nikula
2025-09-02 15:07 ` Mauro Carvalho Chehab
2025-09-01 18:26 ` Mauro Carvalho Chehab
2025-09-02 10:55 ` Jani Nikula
2025-09-02 12:04 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874a85f2154d6b05635d856dcdd85d4715d19d3c.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=akiyks@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@intel.com \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=rdunlap@infradead.org \
--cc=vegard.nossum@oracle.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).