On Tue, 01 Aug 2023 at 15:14:13 -0400, Eli Schwartz wrote:
> My conclusion was that all distros want bytecode, except for Debian,
> which doesn't want bytecode.
Debian does want bytecode, but the Debian Python team's policy is to
generate it at package-installation time, rather than generating it at
package build time and including it in the content of the .deb.
(This allows the same .deb to be used for more than one major version
of Python, without always having to rebuild it, as long as it doesn't
contain compiled extensions; requiring rebuilds for this would be a
problem because the Debian infrastructure cannot currently do fully
automated rebuilds of fully-architecture-independent packages, so doing
those rebuilds would require a package maintainer to sign and upload a
new package with only trivial changes, which would scale poorly across
the very large number of packages that depend on Python.)
> a lintian style "error if you have it" approach
To be clear, Lintian is not the thing that makes this a serious problem:
Lintian is a lint tool, which can give recommendations but does not make
packages' builds fail.
The thing that makes this a serious problem is that many packages' builds
have a list of files that are meant to be installed into each .deb. If a
file not in any of those lists appears, the conservative thing to do is to
fail the build, so that a maintainer can check which .deb the newly created
files should have been in and update the packaging accordingly. Because
Meson has not historically built bytecode automatically, packages that
are built using Meson don't include it in their lists of expected files,
causing their build to regress.
> It's theoretically possible to hardcode Debian yet again and skip this
> install script, but only if running inside a package build. Is there
> even a way to detect this? No idea. Not an enthusiastic topic anyway.
I don't think it should be Meson's job to detect this, which is why I
filed this as a debhelper bug, not a Meson bug. debhelper is the component
that's responsible for telling Meson to use --prefix=/usr when building
a .deb, and this seems analogous.
The way in which this could be considered to be a Meson regression is
that Meson < 1.2.0 never compiled bytecode, and Meson >= 1.2.0 compiles
bytecode by default, which was a behaviour change. This causes Meson-built
Python packages to need to change their behaviour, either by disabling the
new default (which as far as I can see can't be done in a
backwards-compatible way and needs a version check) or by making sure they
can cope with the new default.
CMake and Autotools packages have it easier here, because they don't
fail the build when given an option that is not recognised, so if they
gained a new option whose action we didn't want, we could give them a
-DDISABLE_NEW_THING=ON or --disable-new-thing argument unconditionally.
I'm aware that Meson is intentionally being strict with -D
to detect typos and avoid unintended behaviour, but would it
be possible to add a variant of -D in a future version that
specifically ignores unrecognised options? Perhaps something like
--set-option-if-supported=python.bytecompile=-1?
smcv
