[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unmet <package>:native dependency error when cross-compiling with dpkg-buildpackage

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.


> >  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

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

Reply to: