Hi Guillem,

I think dpkg-checkbuildeps should not reject a Multi-Arch: foreign
package satisfying a build dependency annotated :native. The internal
resolver of sbuild definitely considers this valid and iirc, apt and
dose also think this is valid.

While it is kinda useless, I see two reasons to allow it.

1. Migrating packages to Multi-Arch: foreign. As packages are not yet
   fully tagged foreign, maintainers add :native annotations to help
   cross building. Once their dependency gets annotated foreign, the
   dependee FTBFS. This makes the transition unnecessarily hard.

2. In some ecosystems, we have a mix of foreign and same packages. This
   is popular in scripted languages with extension modules. If you need
   parts of this stack as a build tool, it is far more convenient to
   just annotate the whole stack :native than checking which of it is
   modules and which of it is extensions.

Hope this makes sense. Ccing to d-cross@l.d.o to get more eyeballs on
this.

Helmut

dpkg-checkbuilddeps now rejects db-util:native (which gained
M-A: foreign in bookworm).

It may be useless to annotate an arch:all B-D package with :native (as
src:reprepro/exoerimental currently does), or does the :native propagate
to the non-arch:all dependencies of the annotated arch:all package?

Andreas

Hi Andreas,

The reason to allow :native on M-A:foreign is to ease such transitions.
Nothing else. We could always drop :native in such cases. This allowance
is a convenience only.

An Arch:all package that isn't M-A:foreign, is implicitly considered to
have the "native" architecture (which is defined as the architecture of
the dpkg package). All dependencies of Arch:all packages are native
regardless of whether it is M-A:foreign or whether the dependency is
annotated :native or not. None of this influences the architecture of
indirect dependencies.

Helmut

Hi,

 3. Backporting source packages in situations where a build dependency is
    not yet marked Multi-Arch: foreign in stable but was marked as Multi-Arch:
    foreign in unstable. In those cases, it would be nice if one could just
    add :native to the build dependency such that the same source package can
    be built on both stable and unstable without modifications.

This idea came up when Michael Tokarev asked how to backport src:samba in
#debian-devel.

Thanks!

cheers, josch

13.01.2025 03:49, Johannes Schauer Marin Rodrigues wrote:

After trying to use python3-dnspython:native in Build-Depends[-Arch], which
finally seems to be working, because I actually need the native python, and
because python3-dnspython has finally got M-A:foreign marker, I tried to build
this on bookworm, where python3-dnspython is not marked with M-A:foreign yet.
This failed, with dpkg-checkbuilddeps complaining about unsatisfied build-deps,
despite apt happily provided python3-dnspython.

In order to remedy this, I added an alternative:

  Build-Depends: python3-dnspython:native | python3-dnspython

This, while a bit ugly, actually works on both bookworm and current sid.
First alternative is for apt build-deps, second is for dpkg-checkbuilddeps.

Thanks,

/mjt