Re: Cross-building with python3-numpy
Hi. Thanks for the notes!
Helmut Grohne <helmut@subdivi.de> writes:
> On Sat, Jan 14, 2023 at 03:20:22PM -0800, Dima Kogan wrote:
>> Unsurprisingly, added python3-numpy:any to the Build-Depends complains a
>> LOT.
>
> The :any annotation is only permitted for packages that happen to be
> tagged Multi-Arch: allowed. python3-numpy isn't thus tagged, which makes
> it fairly obvious why it complains.
Yes. I see that now. Two notes:
I was looking at the wiki page, and I think I misinterpreted it to mean
that most of the time you want Build-Depends:something:any. Here's the
line that made me think that:
https://wiki.debian.org/CrossBuildPackagingGuidelines#Use_.27:any.27_qualifier_for_dependencies
Based on the table on that page, I'm now thinking that most of the time
you want Build-Depends:something and the Multi-Arch tags in the dependee
should be set correctly to determine the right architecture to pull in.
I think the wiki should be edited, but I'm not feeling confident-enough
in my understanding of this at the moment to be making changes.
Another question. You just said that python3-numpy isn't
Multi-Arch:allowed. How did you know that? Normally I would "apt show
python3-numpy", but that command doesn't show Multi-Arch tags
>> - One part of being set-up for cross-building is that python3-numpy
>> should be Multi-Arch:foreign. But how do I query this? "apt show
>> python3-numpy" doesn't include the Multi-Arch tags.
>
> python3-numpy is a Python extension and certainly should not be
> Multi-Arch: foreign. That tag is an assertion on the interface of the
> provided package to be architecture-agnostic. Certainly, loading a
> shared library depends on the architecture of the library and the
> program it is loaded into to be equal. We've unsuccessfully tried
> getting this into Debian policy thus far. My own attempt can be found at
> https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign. Does that
> help get a better understanding?
I read that page. But... The interface is in Python. I can write Python
code with 'import numpy', which is architecture-agnostic. The linked
page says
Binary executables generally differ with architectures, but if the
interface that they expose to be used by other software (for example the
command line interface, the content on standard input/output, the way
they process files) does not allow distinguishing the architecture, they
are still considered architecture-independent as far as this area is
concerned.
Does this not apply here?
>> - If somebody were to work on this, would the first step be to grab the
>> python3-numpy sources, rebuild with the Multi-Arch:foreign tag, and
>> then see if it works? I'm about to try that now. Is this the right way
>> to do it?
>
> No. This is probably one of the cases, where :native is the way to go.
> What you want to express here is that mrcal needs a runnable
> python3-numpy rather than one which matches the architecture mrcal is
> being built for. This is precisely, what we have :native for.
OK. Is this the case for all Python extension modules?
Sorry if I keep asking the same questions. This is more confusing that
expected.
Another more complex, but related question. The mrcal needs
python3-numpy in two ways:
- For building the package. python3-numpy:build is needed here
- For the tests. python3-numpy:host is needed there
How does one express that? Simply doing this should be enough, right?
Build-Depends:
python3-numpy:native
Here running tests while cross-building will very clearly not work, but
it's not expected to work anyway, right?
Thanks.
Reply to: