Re: base-apt: Inconsistent priorities between apt-cache and .deb data break offline builds

["'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>]

On Tue, 2026-06-30 at 18:36 +0300, Anton Mikanovich wrote:
> On 30/06/2026 16:24, 'MOESSBAUER, Felix' via isar-users wrote:
> > Dear isar-devs,
> > 
> > we noticed that cross-architecture offline builds are currently broken
> > and single-architecture offline builds differ from the online
> > variant. One failure pattern is the following, whereby the offline
> > isar-mmdebstrap-host fails with an error message like this:
> > 
> > The following packages have unmet dependencies:
> >    libtext-wrapi18n-perl : Depends: libtext-charwidth-perl but it is not
> > installable
> > E: Unable to correct problems, you have held broken packages.
> > E: The following information from --solver 3.0 may provide additional
> > context:
> >      Unable to satisfy dependencies. Reached two conflicting decisions:
> >      1. libtext-wrapi18n-perl:amd64=0.06-10 is selected for install
> >      2. libtext-wrapi18n-perl:amd64 Depends libtext-charwidth-perl
> >         but none of the choices are installable:
> >         [no choices]
> > 
> > The root cause for this is that we ignore the upstream's repo priority
> > overrides when creating the base-apt: reprepro includedeb records the
> > priority from the .deb's own control field, and that becomes the
> > priority published in base-apt's Packages index.
> > 
> > When these priorities differ, the set of packages installed in offline
> > mode are different from the ones in online mode. This per-se is plain
> > wrong, but only surfaces if a now-required arch=all package depends on
> > its architecture specific variant which never has been fetched (because
> > the online bootstrap had access to the prio overrides). For non-cross
> > builds the result is also different, which can be checked by comparing
> > the SBOMs.
> > 
> > There are HACKY ways to re-create the upstream priorities, but IMHO our
> > approach for offline builds is problematic and should be changed:
> > Instead of explicitly recreating the base-apt repo, we better just
> > preserve the upstream apt lists and inject our downloads/deb dir into
> > the apt cache that is used by the build. This would allow us to
> > completely drop the base-apt.
> Issues like that supposed to be fixed by "Improving base-apt usage" 
> patchset.

This rings a bell. Looks like the series could need a revival.

> It should address storing only needed packages, while DL_DIR is just a 
> storage
> for everything without storing any real packages state in it.
> The idea is to have base-apt as an input, while isar-apt is used as an 
> output.

I just checked the series, but this issue is not solved by it, as the
apt lists are not cached but only the packages. This is exactly what
breaks here: The packages have a different priority field than the apt
list.

I'm wondering if a simpler solution is a pull-through cache, like many
people use for cached building of containers (like here [1]). That
let's apt take care of the caching instead of the surrounding build
environment.

[1]
https://github.com/siemens/kas/blob/81bab5294be29de4b64adedce962d36184bfc66f/Dockerfile#L37

> 
> We will look into the issue, starting from reproducing it.

It's easy to reproduce with these steps. You can even further reduce
the set of packages to the bare minimum to reproduce faster.

> > 
> > Reproducer:
> > 
> > 1. kas-container menu, select qemuarm64 machine, build
> > 2. mv build build-online && mkdir build && cp -rf build-
> > online/downloads build/
> > 3. kas-container build .config.yaml:offline.yml
> > 
> > offline.yml:
> > header:
> >     version: 14
> > local_conf_header:
> >     offline: |
> >       ISAR_USE_CACHED_BASE_REPO = "1"
> >       BB_NO_NETWORK = "1"
> Do we need such an option in kas menu?

Probably? :) At least I did not see this option, but the variables are
documented.

Felix

-- 
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/068441b599000a64dfee36800f1949ecda868662.camel%40siemens.com.