embed fscrypt into eve-alpine

[giggsoff]

We can create own packages and install them using the same mechanism
into required packages.

[deitch]

I like the idea of packaging external dependencies as apks. It is an approach others are taking, notably chainguard with their melange and apko.

I do not think this should be in pkg/alpine though. That base updates at its own pace, and has a lot of downstream dependencies. I think I would sooner see this in its own pkg that can get included. So maybe we have pkg/dependencies that includes lots of external dependencies, each of which is built into apks. Then the final downstream (e.g. pkg/pillar/Dockerfile) can be (still need to work out how this would work)

FROM lfedge/eve-dependencies:hijkl AS depends

FROM lfedge/eve-alpine:abcdef AS base
ENV PKGS bash curl git # etc. etc.
RUN eve-alpine-deploy.sh

An alternative might be not to use apks, but yes have a dependency image. So we build and install lots of dependencies for the dependencies image, and the downstream looks like:

FROM lfedge/eve-dependencies:hijkl AS depends

FROM lfedge/eve-alpine:abcdef AS base
ENV PKGS bash curl git # etc. etc.
RUN eve-alpine-deploy.sh

COPY --from=depends /pkg/fscrypt /src/fscrypt

On the other hand, my concern with a single upstream dependencies is that it can get big and bloated too. We would have to update it for everything that changes in pillar, and in debug and...

[rouming]

Petr, do you have an understanding what we put inside a package or what we put inside a container? If you dont we need to define that. Otherwise there will be a zoo of build approaches. Also for me is not clear what benefits do we have hiding a tool inside the alpine package rather than a container. For me this only increases complexity of the build system, because now (as a developer) I should be aware how to construct an alpine package and frankly I don't have any interest to grasp this knowledge.

[giggsoff]

Good point, it adds complexity of wrapping build process. Unfortunately I have no good answer what I would like to see as wrapped packages and what to leave as a separate package.

This draft PR inspired by two another PRs:

1. disable network for package builds, use only ADD to get network things, fix any packages that need changes to build #2861 where we want to avoid downloading from external repositories during build. We want to concentrate build process into one place, I assume that eve-alpine is a correct place to prepare dependencies.
2. Add example scripts for how to extract source files #2867 where we will have scripts to grab sources. And one of them is parsing of APKBUILD files. We can put additional logic in the script based on package prefix (eve-) or maintainer or something else and point onto our own repo I introduced here instead of upstream alpine.

I try to imagine how to refactor dependencies we have and wrap them into some kind of pattern we will able to parse later.

[eriknordmark]

With #2861 do we still need this? I think @deitch approached fscrypt differently in that PR.

[deitch]

do we still need this?

No, we do not need it. This is an alternate approach, and one that is well worth considering. On the other hand, as @giggsoff and @rouming raised above, it increases complexity of the build process not just by adding a step, but also by requiring a different packaging process.

I would like us to keep this open to discuss:

• is apk a good packaging option?
• is pkg/alpine the right place for it, or should it be elsewhere?

[giggsoff]

Let me close this until we will decide where to locate packages