Re: Unmet <package>:native dependency error when cross-compiling with dpkg-buildpackage
Hi!
On Wed, 2021-12-08 at 20:54:47 +0100, Johannes Schauer Marin Rodrigues wrote:
> Quoting Guillem Jover (2021-12-08 20:10:22)
> > The swig package is arch:all m-a:foreign, which is disallowed as the
> > target of a :native arch-qualified dependency, and thus the dependency
> > is not satisfiable. See:
> >
> > https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/tree/doc/multiarch.txt?h=pu/doc-multiarch-spec
> >
> > BTW, you might want to rise this kind of question in the
> > debian-cross@l.d.o mailing list.
>
> I hope this is not yet written down anywhere but what is the rationale for
> disallowing a foo:native dependency on a m-a:foreign package?
I was not sure, so I rethought the rationale from scratch, then recalled
there could be a bug about this. Found #827628 and #854438 (! :D), which
pointed me to:
<https://wiki.debian.org/Multiarch/MissingRationale#Why_do_M-A:foreign_packages_not_satisfy_:native_qualified_dependencies_in_build-dependencies.3F>
And it seems to match my rethought rationale, so that's a good sign. :)
> I see that the table in the doc-multiarch-spec branch mirrors the original
> table from https://wiki.ubuntu.com/MultiarchCross where foo:native on
> m-a:foreign is also disallowed.
>
> It makes sense that the other disallowed combinations are with foo:any as :any
> explicitly exists for m-a:allowed packages. But why also disallow :native for
> m-a:foreign?
The point is that either of the markings is wrong, the relationship is
nonsensical, either the interface is arch-dependent and thus can be
requested to be pkg:native, or it is arch-independent and the target
can be provided as foreign.
> I would argue that:
>
> a) this argues the principle of least surprise -- if I am writing my
> Build-Depends and I know I want the build-architecture version of the package,
> then a package that explicitly claims to satisfy foreign architecture should
> satisfy the :native relationship
See above, to me that indicates something broken somewhere, and the idea
of what kind of interface is being provided or depended on is confused.
> b) if we mark a package that was m-a:no before as m-a:foreign, then we now
> also have to clean up all the B-D that were using :native before
True, to me though that perhaps implies that we should request people
to not set :native against M-A:no until they have evaluated whether the
target is really not M-A:foreign?
> IMHO, that table cell should not be "disallowed" but "any, preferably
> DEB_BUILD_ARCH" just as it is for a normal B-D foo on a m-a:forein package.
>
> So what is the reason for this being disallowed in practice?
Not sure whether the existing rationale is (re)convincing, but it
seems useful to me, as I think of build relationships as possibly
being more strict than run-time ones in this case, where the context
is different as it's easier to fix or modify these relationships as
you already have the source in front of you, and it is something a
user tends to perform less often than installing/removing the same
built binary package, and can help easily detect this kind of
problematic relationships.
> P.S.: whatever the reply to my query probably makes a good text for the "XXX
> Document discrepancies and their rationale" part of multiarch.txt :)
For now I've added this:
diff --git a/doc/multiarch.txt b/doc/multiarch.txt
index eaa5ea9c6..fb68bacc4 100644
--- a/doc/multiarch.txt
+++ b/doc/multiarch.txt
@@ -288,6 +288,19 @@ architectures we will have knowledge of.
With «any (<type-arch>)» meaning that while any architecture would do, the
preferred one is <type-arch>.
+The build-time satisfiability includes disallowed relationships because
+these help detect nonsensical relationships. This difference compared
+with the run-time behavior is because it tends to be easier to modify
+the source once you have it around.
+
+The pkg:any with anything that is not M-A:allowed relationship is disallowed
+because the requested relationship is not getting respected.
+
+The pkg:native with M-A:foreign relationship is disallowed because that
+indicates either (or both) markings is in error. Either the interface is
+arch-dependent and thus can be requested to be pkg:native, or it is
+arch-independent and the target can be provided as foreign.
+
[ XXX Document discrepancies and their rationale for difference in
satisfiability for pkg:any, and for not honoring the distinction between
Build-Depends and Build-Conflicts like with run-time deps. ]
--
2.34.1
But, as usual, I'm happy to reconsider the current behaviors if we
think they are rather problematic or make no sense.
Thanks,
Guillem
Reply to: