• Re: Unmet :native dependency error when cross-compiling with d

    From Johannes Schauer Marin Rodrigues@21:1/5 to All on Wed Dec 8 21:10:01 2021
    (moving this to debian-dpkg@ for a more on-topic 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?

    Thanks!

    cheers, josch

    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 :) --==============v88215255858054252=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmGxDYMACgkQ8sulx4+9 g+FxMw//QmVYSzlJEYcETxAuOPEPsKhpV8RA/a7b8z6osyyOiAdhMneFpfz96n3V QyjBi6NLJCX/v/V+7i2xgS2fhBFuNHXSXd0cWTXQ57AZOZ+4AwLvujOJKkzdMLXl bG5GkewQR3dcwwx2Tnlll8kMJOhyTLHjQYBbhd7d2gKsbXABdOLGocc+b+sCt/6B AxPt8c42ZLr4EAFU8IJD9ruKgD/VpBTAbHjXxP7Gm720fGNzPkmiO6Flb8mfbjSQ 3zGvRz0PqkupWP6feE/68w4jlPWRqs1TnicF9Qbgt6/egUF9yj2xqku/yGYh2NHj YU7avaj+gaxF5MTlIn0uGB6ni8aKutTU43nYh34W1w9Zka/34ZyTqsna+HZBWqxp SIrrpx/iImSRMre5CCpg+pKnHfpP85/ai2Fc0Y59c8jL334gyvwT/J4IYAGTH1bX waHNPbRsXQ1d+lHgb1hDFCebadIKiVgD9p40a/EBkcDPTdd/1kNG9rxGvtggo89g xd4OwjQDliRDId3D8XVRrtv/MIUK9SQeO/1hOraGIvOIrfrFLPfDZ72biuwOPDQL YJGxAyhI2FXdjXPz3g6/ewn8ch3CjQnXpVeqdRMUPw+ac1kWeRVK/lfA2mjtAmLM jQLTgGWy0RnclmeMa0VBCHrGMX7d8gDJHtvbIibe1PgfQKvAArk=
    =1fVe
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Johannes Schauer Marin Rodrigues on Sat Dec 25 10:00:02 2021
    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 no
  • From Johannes Schauer Marin Rodrigues@21:1/5 to All on Sun Jan 23 19:00:02 2022
    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
    --==============36401066067851315=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmHtk/4ACgkQ8sulx4+9 g+GpTw//bRXF3az0735VMBnxiHTw+Pk/OwqQk0T243HosRvWopyMQB1JTnhCHFQz 0diCzDHV6jIUql7kFw8YWOKGSVFcrb38K5Jm9AHpxs9x9jFaXQvtOGqDMPmKiJEw 1F6nqBJmKLGaq+xNdNWgecrRG5jxFAMkrBLZveE9NbOtW8eyoDrfRSTGFiZvpU9N NKzdT7uhLWwu4kmqD9nrdMlJlrmygkZsFF21PgAax+BqCZPE37XL5WSJcP8cYZGl ICrtydwpBSGp6IBP1AngiJ1SSKBwSCeV45mw6/eFGG6gKdLZo4qcliZdPonTi5St OR7S2ZociHSVSXqxl9oAhz/Tqb/HmVmTFhtIjoAn7LjNl4QxAaPFEi4jQeSzV6yZ YTqf5qqaziNC6I9DkH4xi0J7c9SRDKW/iiOLBI/PSSFVXW+pyfWguNvIfVG6chHI ErVq8GhJ+t4qq/WXiXoRM9QxF1ARMnbTwB/13y1sRmJS7P5fh0sfE9QzOupRvLX9 w8QNr/neltaG+bIivIexLLr2Vkj552vBMci9xy+5f0a5vjxR2GLdAhMZruGlqlbZ Tke48IxLfAuVRjn/MCwg/Ptzzekkqccw59JJv3s4HJRj7Es2sfTjGNMiBkUpQWKN 0Kkp51/DuNt817zsGu6JBuCXstvOVYYXBgj+lY7cTLMY6/dzrEQ=
    =iMPk
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)