Re: suitability of Multi-Arch: allowed for cython?
Hi Étienne,
On Thu, Jun 01, 2023 at 11:17:45PM +0200, Étienne Mollier wrote:
> While reviewing the cross-build of abpoa[0] as discussed with
> Helmut at Hamburg, I noticed that I tripped on the carpet with
> qemu-aarch64 binfmt running foreign architecture binaries during
> abpoa cross build; the python3.11 run was arm64. When trying to
> resolve the issue, I ended up in the situation of observing that
> I could cross build abpoa by marking the cython3 build
> dependency as :native.
thanks for the nice time in Hamburg and thanks for continuing with this
little adventure. :)
You'd definitely not be the first to add :native to cython3. Questioning
whether this is right is a good approach.
> cython3 is roughly a transpiler that converts python3 or pyrex
> into C code. As far as I could witness, the output C code was
> not particularly architecture dependent on first sight, but I
> may be wrong. I spent some time in the wiki pages dedicated to
> Multi-Arch support[1], but I didn't manage to identify what
> makes a package eligible to Multi-Arch: allowed. I was hoping
> that perhaps, cython3 would be eligible to that marker, but I
> don't know what to be careful about before granting such marker.
> I noticed that the package had maintainer scripts, although
> produced by dh-python, not sure whether that would interfere.
I think we basically have three options at hand here.
1 Mark cython3 Multi-Arch: foreign and be done (except for having to
remove the existing :native annotations).
2 Mark cython3 Multi-Arch: allowed and add :any or :native on most
(all?) uses.
3 Keep cython3 implicitly Multi-Arch: no and add :native more.
Given the existing evidence, I think that 3 is strictly worse than 2. So
the main question is whether 1 is correct. When 1 is correct, it is
strictly better than 2.
> Would marking cython3 as Multi-Arch: allowed be the correct
> approach here, or is this one case where :native has to be used?
> Or am I missing something else entirely?
"allowed" basically says that the consumer is allowed to decide whether
an architecture constraint should be dropped via a ":any" annotation
whereas a ":native" annotation maps the annotated package to the build
architecture. While both typically have the same effect in situations
where both work (i.e. Build-Depends on M-A:allowed packages), their
meaning is subtly different.
The real question here is whether there are ways to use cython3 such
than it behaves in an architecture-dependent way. Your reasoning that it
outputs platform-independent C code is a good start. However, the
cython3 package also includes Python extension modules. Do these modules
contribute to the API of the cython3 package? If yes, it cannot be
Multi-Arch: foreign. If they are considered an internal implementation
detail, the Cython module should be moved to a private path. So I think
we can already conclude an initial answer: cython3 cannot be Multi-Arch:
foreign as is.
What constitutes an interface of a package can be subject to change
though. In changing cython3, it could be possible to eventually mark it
Multi-Arch: foreign. A very simple thing could be splitting the Cython
module into a separate python3-cython binary package. Then we could
argue that while the Cython module is used by cython3 (is it really?)
that use constitutes an implementation detail and any consumer of the
Cython module must depend on python3-cython. By doing so, the actual
users of the Cython module would get matching extensions (since we
couldn't mark python3-cython M-A:foreign), but those users that only
interface with the cython3 executable would not need it (directly) and
therefore cython3 could plausibly become Multi-Arch: foreign.
So as is often the case, the answer is somewhere in between. The problem
here is that any decision here has implications for users (stuff that
Build-Depends) and revising the decision later implies changes all over
the place. Since the first option is quite clearly the best (if right),
trying that and therefore splitting cython3 seems worth a try. Next
tasks:
a. Understand whether there is any other architecture-dependent aspect
in cython3 and raise it here.
b. Split cython3 into python3-cython.
Any takers? I didn't say cross building was easy. ;)
Helmut
Reply to: