public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'Andreas Naumann' via isar-users" <isar-users@googlegroups.com>
To: isar-users@googlegroups.com
Cc: Andreas Naumann <anaumann@emlix.com>
Subject: [RFC 0/5] Improving multiarch support for arch-incompatible packages
Date: Wed,  1 Oct 2025 12:59:24 +0200	[thread overview]
Message-ID: <20251001105929.3731537-1-anaumann@emlix.com> (raw)

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

-- 
2.43.0

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/20251001105929.3731537-1-anaumann%40emlix.com.

             reply	other threads:[~2025-10-01 10:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-01 10:59 'Andreas Naumann' via isar-users [this message]
2025-10-01 10:59 ` [PATCH 1/5] rootfs: Do not recursively deploy every dependent package 'Andreas Naumann' via isar-users
2025-10-01 10:59 ` [PATCH 2/5] multiarch: handle DPKG_ARCH=all case for transitive deps 'Andreas Naumann' via isar-users
2025-10-01 10:59 ` [PATCH 3/5] image: Do not inherit multiarch 'Andreas Naumann' via isar-users
2025-10-02 12:09   ` 'Jan Kiszka' via isar-users
2025-10-02 14:17     ` 'Andreas Naumann' via isar-users
2025-10-02 14:55       ` 'Jan Kiszka' via isar-users
2025-10-06  7:05         ` 'Andreas Naumann' via isar-users
2025-10-01 10:59 ` [PATCH 4/5] multiarch: Prevent providing incompatible native packages 'Andreas Naumann' via isar-users
2025-10-01 10:59 ` [PATCH 5/5] multiarch: Do not re-extend real -native recipes 'Andreas Naumann' via isar-users
2025-10-02 12:10 ` [RFC 0/5] Improving multiarch support for arch-incompatible packages 'Jan Kiszka' via isar-users

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251001105929.3731537-1-anaumann@emlix.com \
    --to=isar-users@googlegroups.com \
    --cc=anaumann@emlix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox