On Mon, Jul 25, 2022 at 12:41:16AM +0500, Andrey Rahmatullin wrote:
> On Sun, Jul 24, 2022 at 08:30:42PM +0100, Julian Gilbey wrote:
> [...]
> > > > are they all effectively Multi-Arch: no? Is this worth thinking about
> > > > in the longer term?
> > > What do you propose?
> >
> > I think the fix to bug #812228 might have done the job nicely ;-)
> If it actually ships extensions, the "it should usually get a dependency
> on the Python interpreter for the same architecture" part should still
> apply as far as I understand it.
Thanks Andrey!
OK. So let's dissect this tag info and see where we're currently at.
Explanation: This <code>Multi-Arch: same</code> package uses
<code>pycompile</code> or
<code>py3compile</code> in the specified maintainer script.
.
<code>py{,3}compile</code> are tools used to byte-compile Python source
files. It is typically run on installation of Debian packages that ship
Python modules. However, they do not support installing several
architectures of the same package and this is not Multi-Arch: safe.
This is now out-of-date: firstly, we can presumably get rid of the
pycompile mention, as there are only a tiny handful of Python 2
packages still around, and we're trying to get rid of them.
Secondly, py3compile now supports installing several architectures of
the same package; see the closing changelog message on bug 812228:
Architecture-qualify py*compile and py*clean calls in maintainer scripts,
for architecture-specific Python packages. This allows co-installation
(and even concurrent unpacking) of different architectures of a package.
So the rest of the paragraph is also out of date.
If the contents of the package is not architecture dependent, it should
usually be made binary-all.
That is still certainly true.
If the contents of the package is architecture dependent, it should
usually get a dependency on the Python interpreter for the same
architecture. This is a dependency in the form of <code>python3</code>, not
an architecture-qualified dependency such as <code>python3:any</code> (which
can be fulfilled by the Python interpreter for any architecture).
This is interesting; dh-python gives the dependency:
python3 (<< 3.11), python3 (>= 3~), python3:any
which has both same-architecture and qualified architecture
dependencies; obviously the same-architecture one "wins". But this
paragraph is probably unnecessary for most dh-python-using packages
(though it doesn't seem to harm).
If a dependency on the Python interpreter for the same architecture
exists (usually generated by <code>dh-python</code>), the
<code>Multi-Arch: same</code> has no effect and should be dropped.
Ah. I see the point. Because python3 and python3-minimal are
Multi-Arch: allowed, the different arches of python3 are not
co-installable, and so there is no point in labelling the
arch-dependent module packages as Multi-Arch: same; they still could
not be co-installed.
See-Also: pycompile(1), py3compile(1), Bug#812228
This list can probably be trimmed down to py3compile.
I hope this reasoning is useful; shall I pass it on to the lintian
folk?
Best wishes,
Julian
