Re: [PATCH 1/1] fix(dpkg-build): deploy debs via shared sstate dir

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

On Thu, 2026-07-30 at 16:41 +0200, Jan Kiszka wrote:
> On 29.07.26 13:18, Felix Moessbauer wrote:
> > The built debs were stored in a WORKDIR-internal plaindir and consumed
> > from there by do_deploy_deb. do_deploy_deb is a task that mutates
> > the external isar-apt repository and can therefore never be sstate
> > cached, so it always runs and relies on the plaindir being present on
> > disk.
> > 
> > When do_dpkg_build is served from the sstate cache, that WORKDIR-internal
> > plaindir is not guaranteed to be materialized (e.g. when the task is
> > covered via hash equivalence without a setscene restore). do_deploy_deb
> > then runs against an empty deploy dir, passes an unexpanded glob to
> > dpkg-deb and aborts the build.
> 
> Not getting it: why is dpkg_build_setscene not properly filling
> DEPLOYDIR then? We told it that the build will fill it, it picked things
> up from there for caching, and it should refill it when it skips the task.

Well... That's unfortunately how bitbake works. The artifacts in
plaindirs are not under sstate manifest control (the thing that also
blames you if you deploy artifacts with equal name but different
content to the same location). That also means they are removed on
"clean".

In other words, the staging/copy step only runs when the task's
setscene is actually executed (i.e. the sstate object is unpacked).  It
does not run when the task is considered to be already executed based
on hash equivalence. In this case, the restore directly happens from
the sstate cache via it's manifest tracking.

Don't ask me WHY bitbake internally implements it like that...

Hash equivalence is described in [1], I still can only find this detail
in the sstate sources (and runqueue.py line 2324ff) ...

[1]
https://docs.yoctoproject.org/overview-manual/concepts.html#hash-equivalence

> 
> > 
> > Fix it by deploying the debs into a shared, sstate-tracked DEPLOY_DIR_DEB
> > via sstate-inputdirs/sstate-outputdirs.
> 
> This is creating yet another copy of the generated deb files in our
> build dirs. Sounds inefficient, specifically when we have larger artifacts.

Yes, unfortunately. But we need to properly deploy these artifacts. One
optimization would be to hardlink the isar-apt cache pool files to
these deployed files, however I'm not sure if this can practically be
implemented.

I'm not so much worried about the additional space consumption. A way
bigger waste of space are the left-over chroots.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

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