mbox series

[RFC,0/5] Improving multiarch support for arch-incompatible packages

Message ID 20251001105929.3731537-1-anaumann@emlix.com
Headers show
Series Improving multiarch support for arch-incompatible packages | expand

Message

Andreas Naumann Oct. 1, 2025, 10:59 a.m. UTC 
Fixing the recursive dependency issue of "all" packages, as proposed by
Felix, showed that currently the Isar multiarch support seems to assume that
custom dpkg recipes are always valid for the host as well as target architecure.
Or, if they are not, Isar would make an effort to redirect if possible.

However, there are situations where this is not the case, e.g. packages
supporting a certain architecture only or packages intended for the host
without full crosscompile compatibility.

This series is to allow for such cases by supporting DPKG_ARCH being set
to a specific architecture if it is not truly "all" or "any".

The first patch fixes unnecessary, possibly incompatible packages being added
to the overall rootfs dependency chain. It's also sort of an alternative solution
to the fix that Felix provided in his original patch which I took the
freedom to rework to contain the recursive dependency fix only.
The reason I'm going another way is that I was looking for a way to
generically handle all incompatible packages, not just "Architecutre: all".
Of course this comes with the "drawback" that "all" packages, suited to be
compiled in and only for -native, need to be added with their -native name
whereever they are depended upon.

As for reverting recrdeptask: IMHO, the alternative to keeping it would be to
not being able to use cross-package inter-task dependencies, like Jan's
patch for avoiding the duplicate creation of the dpkg-source package
does. That would be kind of limiting.
As for the cache related reasons for which recrdeptask was actually
introduced: I could not find the do_prepare_build-A -> do_deploy-B
dependency, but only do_deploy-A -> do_deploy-B. So I'd just hope that
this is no longer a problem, but havnt invested testing effort to prove so.

The image patch is preparational, so images are not unintentionally
skipped by the actual main patch (#4) which handles incompatible
packages.
It was made before handling of packages with unset DPKG_ARCH variable
was added, so it's no longer strictly needed, but may be worthwhile
anyway.




Andreas Naumann (4):
  rootfs: Do not recursively deploy every dependent package
  image: Do not inherit multiarch
  multiarch: Prevent providing incompatible native packages
  multiarch: Do not re-extend real -native recipes

Felix Moessbauer' via isar-users (1):
  multiarch: handle DPKG_ARCH=all case for transitive deps

 meta/classes/image.bbclass     |  1 -
 meta/classes/multiarch.bbclass | 33 ++++++++++++++-------------------
 meta/classes/rootfs.bbclass    | 19 ++++++++++++++++++-
 3 files changed, 32 insertions(+), 21 deletions(-)