ioc: copy locally installed software from build stages.

[henriquesimoes]

Software, other than shared libraries, may be built in the first stages, but are currently not available in the resulting IOC image. Copy the entire /usr/local tree in all IOC stages, so that locally installed binaries and configuration can be usable at runtime.

This allows us to build custom versions of applications during build phases and install them at IOC images, centralizing and making it easier to track how they are built. In addition, IOCs can also install custom files which will be available at runtime in a known location. Still, IOCs themselves can also be installed in FHS-compliant paths inside the container as any other packaged software, allowing them to make use of tools based on system-installed artifacts (such as env executable discovery).

[ericonr]

Don't we have scripts here which are only relevant for the image build phase? 🤔
Like lnls-get-n-unpack

[henriquesimoes]

You are right. But after-build stages wouldn't be aware of such things. We must remove everything (including lnls-get-n-unpack) beforehand if we don't want it to be in the final image, otherwise we won't shrink the image size (which is related to #19).

[ericonr]

So it makes sense to wait for #59 before merging this. What do you think?

[henriquesimoes]

I'm okay with it.

[ericonr]

Do we need this for ADPimega at the moment?

[henriquesimoes]

Do we need this for ADPimega at the moment?

Nope. We're installing the required libraries at build and runtime. We wouldn't need to install libpimega at runtime if we had this PR merged.

cnpem/ad-aravis-epics-ioc#1 is depending on this to allow us to copy symlinks installed by the IOC under /usr/local/bin. If we make this something handled by epics-in-docker itself, it wouldn't need it. (Probably such internal implementation would, though.)

[ericonr]

If we make this something handled by epics-in-docker itself, it wouldn't need it. (Probably such internal implementation would, though.)

Are you suggesting the IOC build script copy executables itself?

[henriquesimoes]

Are you suggesting the IOC build script copy executables itself?

Not necessarily. I was referring to the creation of a symbolic link at, say, /usr/local/bin/ioc pointing to /opt/$REPONAME/bin/linux-x86_64/<ioc-binary>. It could be a hard copy as well, though. In either case, we'll rely on this PR to copy the link or the binary itself from the build image to the final one in order to make this step actually meaningful.

[ericonr]

It could be a hard copy as well, though. In either case, we'll rely on this PR to copy the link or the binary itself from the build image to the final one in order to make this step actually meaningful.

I think it would be possible to support defining only the link or hard copy without requiring a copy of everything under /usr/local. If it makes sense to do that instead of simplifying the recipe, I don't know. Especially considering the additional usefulness of this allowing RUNTIME_TAR_PACKAGES to be basically unused in favor of BUILD_TAR_PACKAGES.

[henriquesimoes]

Are you thinking about an explicit rule copying only the link (or binary) in a hard-coded way or a variable-based one?

If it is the latter, it would also work to get rid of the RUNTIME_TAR_PACKAGES. It would be more verbose to name everything to be copied explicitly, of course. But that's somewhat related to your comment in the other thread: #133 (comment).

However, it also assumes we know what's relevant beforehand, and we can always properly name them. I think that should be true given the build artifacts are deterministic.