While I can live wit this, it is unnecessary (and IMO confusing). The docker pattern of creating large RUN lines is to avoid bloating the final image with unneeded layers.

But we achieve that in the final FROM scratch AS builder anyhow.

But here I need to conditionally run the operations, so the long list of commands has to run on amd64, while the very last mkdir is for arm64 to avoid failing the COPY operation later.

Are you suggesting to separate each command on it's own RUN and put an if everytime to check if the platform is amd64?
Wouldn't that be even more noisy?

Meanwhile I realized I've slightly messed up the order between the cppcheck step and the cleaning of the apt database.

Oh, I didn't even notice the if. I don't know if there's anything cleaner.

cppcheck step and the cleaning of the apt database

If you do the layers right, you don't need to clean the apt db.

If you do the layers right, you don't need to clean the apt db.

How do you mean?
The only way I know to leave things behind is to do a separate FROM x AS y as we've been doing and then copy portions from it, but stuff installed from apt can land in various folders, I don't know if it's worth to try to piece things like that in the final step via copies?

Yes, I think so. Still from apt can get sprayed everywhere, and it's hard to clean up. But that doesn't matter if you're throwing the whole container away and only doing COPY --from=cppcheck /root/cppcheck/install/usr/local/ /usr/local/

I think we can probably keep this, but I find it hard to read.

The apt cleaning step is not meant for the stuff installed in the cppcheck step, but for the initial installation of packages:
https://github.com/osquery/osquery/pull/7455/files#diff-dc9d3419831a3c9190d25d38293841d6a8268c2146641a5b9b55e7ee70927669L4-L28

This stuff installed here has to persist, it's not thrown away.

Maybe I'm doing it wrong; the objective is to remove the cached packages that the very first step has left behind, so the intention is to run those commands in the base3 layer, which is the source for base4, which is the destination for the cppcheck layer.

To be even more clear, I hope, the way I'm thinking about it is that we have a base layer/view which will contain the final state of the container.
This is the view where we do the first installation of various packages via APT; what APT installs has to be permanent and found in the final view.
The difficulty of APT changing many things in the system I was mentioning is this: If it was easy to know perfectly what are all the files that APT changed, excluding its caches, then we could copy all of those into a new layer where APT has not run, and so you drop everything else behind.
But this is not the case.

Then what happens is that the base view/layer is copied multiple times (new layers are created) and new pieces are added to it.

Then we come to the cppcheck layer; while it is based from this evolving view, it's temporary. Only a piece of it it's copied, because it's easily contained under a single folder and thrown away.

Finally we cleanup the base view/layer from stuff we don't need.

I think we're talking cross purposes, or mostly agreeing, or something like that.

I'm observing that the length of the RUN command in the cppcheck container makes it hard to follow, and that since we're going to throw most of this container away later, we can use multiple RUN lines.

You, reasonable, pointed out that it's a mechanism to switch on platform. And possible the simplest.

For cleaning up the apt db stuff, if we wanted to toss any rm things in into base3 that seems reasonable. I don't think we need to have a working apt system at the end of this,

This adds a second COPY, which I think counts as a second layer. Somewhat mixed on that.

I'd probably:

FROM base3 as base4
COPY --from=cppcheck /root/cppcheck/install/usr/local/ /usr/local/

FROM scratch as build
COPY --from=base4 / /

This is me not knowing enough Docker and having the wrong expectations; I'll change it.

I don't love this architecturally, but AFAIK it's what we get