Ooo ooo, I gotcha. It’s because snapcraft fetches
stage-packages before it executes the
pull step for the part. In other words, it’s architected such that the
pull step can depend upon
stage-packages (and indeed, some plugins have this dependency, such as the python plugins. Sadly, snapcraft has no way of knowing whether or not the
stage-packages are required to pull any given part, so it errs on the safe side and assumes that’s always the case. And indeed, extracting
stage-packages to another part means that they’re not needed to build the part either, which means… why are they
stage-packages for that part in the first place? Making them their own part is a perfectly reasonable thing to do.
Understandably, you’re ever so slightly misunderstanding those terms.
stage-packages aren’t named to correspond to lifecycle steps (e.g.
stage, etc.). Rather:
build-packages are installed onto the host building the snap in order to help build the snap (or the part). These are typically the -dev package that includes headers and stuff that aren’t wanted in the snap, but are required to build it in the first place. Everything you declare here will essentially be
apt install'd onto the machine building the snap before the snap building process begins
stage-packages aren’t installed onto the host, but downloaded and unpacked (i.e. staged) into the snap itself as a component within the part in which it is declared. These might be the runtime version of the -dev package that is a
build-package (e.g. perhaps
libfoo-dev is the
libfoo is the
Does that clarify things a little?