CCing debian-java, as I should have done from the beginning.FYI, this thread started at <[🔎] 0963cc87-fc4e-c13a-7062-adab5319ce85@debian.org">https://lists.debian.org/[🔎] 0963cc87-fc4e-c13a-7062-adab5319ce85@debian.org> and is about cross-compiling a JNI-package (libcsnd6-java)
On 2/22/22 05:22, Helmut Grohne wrote:
Hi IOhannes, I can only give a partial answer here, but maybe it helps demystify things a little.
thanks for your detailed answer.
You figure that any "Multi-Arch: allowed" can be implemented by a layer of indirection? Consider package foo being M-A:allowed. Now you could add a package "foo-any" being "Architecture: all" + "Multi-Arch: foreign" + "Depends: foo". Now a dependency on "foo:any" is roughly equal to a dependency on "foo-any". (The difference being that the former allows satisfying the dependency using a non-native "foo", but that's almost never what you want.)
so should i request a "default-jdk-any" from the java packaging team?
Your comparison to Python is correct though. The Python packaging is quite similar in this regard. When you want to cross build Python extensions, you need to B-D on "python$something-dev:any, libpython$something-dev" (where that $something usually is empty, a version or "-all").
right.
However, I do think that for both Python and Java the packaging looks backwards to me. Both of them comfort a niche use case at the expense of the standard use case: Both make it easy to depend on a non-native compiler/interpreter while making the standard use case of cross building hard. Contrast that to perl. We've established this magical package "perl-xs-dev" now. You build a perl extension? You add perl-xs-dev to Build-Depends. It takes care of pulling the build architecture interpreter together with the hosts library. It wouldn't be hard to mirror that for Python. An empty "python-xs-dev" package could be "Architecture: any" + "Multi-Arch: same" + "Depends: python3-dev:any, libpython3-dev". It's not what we've settled on now and transitioning all Python extensions would amount to a huge cost.
but at least, python already *has* a (documented) way to build extensions, even if it looks backwards to you.
i haven't found anything for java yet (using codesearch.d.n) now while i'm typing, i finally found my way around using grep-dctrl ``` grep-dctrl \ -s Package,Build-Depends \ -F Build-Depends,Build-Depends-Indep \ "default-jdk-headless:" \ /var/lib/apt/lists/*Sources ```and lo-and-behold this returns a single package "java-atk-wrapper", which has "default-jdk-headless:native" in it's B-Ds. looking up where this comes from, i see it was a fix proposed by some "Helmut G" in order to close #885129.
so i guess using "default-jdk-headless:native" is not totally wrong. should this be documented somewhere (e.g. in the wiki[1])? or are there some better (conrete) options (e.g. on the java team side)? gfamrfds IOhannes[1] https://wiki.debian.org/CrossBuildPackagingGuidelines#Hints_for_specific_groups_of_packages
Attachment:
OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature