Quoting Guillem Jover (2021-12-25 09:57:26) > > 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. Understood. > > 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? This is also a good point. > > 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. Thanks for explaining it. I have now come up with another problem regarding :native. Currently, sbuild creates a dummy binary package to install build dependencies. Since :native is only allowed in Build-Depends, sbuild either removes the :native (for native builds) or replaces :native with the build architecture (for cross builds). This is wrong because it doesn't keep the property that :native cannot be satisfied by a M-A:foreign package. After the translation, the dependencies of the dummy package will be satisfiable even by a M-A:foreign package and this means that the build succeeds in installing the build dependencies and only later fails with dpkg-checkbuilddeps: error: Unmet build dependencies: foo:native I don't see any way to easily fix this problem. > > 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 Thank you! cheers, josch
Attachment:
signature.asc
Description: signature