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.
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 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?
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
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
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?
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 :)
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 292 |
Nodes: | 16 (2 / 14) |
Uptime: | 179:41:15 |
Calls: | 6,616 |
Calls today: | 3 |
Files: | 12,165 |
Messages: | 5,314,109 |