Actually, we want to have ACL enabled by default on systems that supports ACL and deactivated on systems that do not support it. Why does it break hermeticity? It's just another dependency?

Actually, we want to have ACL enabled by default on systems that supports ACL and deactivated on systems that do not support it. Why does it break hermeticity? It's just another dependency?

To have a hermetic build you need to provide a hermetic acl dependency. Just adding -lacl is not hermetic, it just takes whatever acl is available on whatever host the build happens to run on - if it is even available: acl isn't installed by default in every linux.

If there was an acl Bzlmod or WORKSPACE version available iceoryx could depend on that and just always enable the acl feature. I don't know that this exists though.

Keep in mind, I'm not that familiar with bazel, so this questions might sound stupid.

How can a build be hermetic if the hermetic environment can have dependencies that are not specified in the build system? This kind of sounds like a flaw in bazel?

Anyway, I'm not strictly against this. I just want to understand the reasoning and explore if there are other options which do not risk to have silent breakage on users who already depend on the default behavior of v2.95. That was the main reason to have the auto flag in the first place, since the bazel support was added to the main branch years ago and the ACL feature flag only a few months ago.

So, just for fun. Let's assume we would like to keep the default for Linux for all users to depend on libacl, what would be necessary to make the build hermetic?

There are no stupid questions :)
Bazel makes it possible to have fully hermetic builds. It doesn't mean that anything you do is automatically hermetic.

For example many people use new_local_repository() to pull in pre-built system-installed OpenCV as that is exceptionally hard to build from source. At that point you have a build that works but requires you to have OpenCV installed on the system. Bazel doesn't install OpenCV for you and you must ensure you have the correct version with other means. This is not a hermetic build.

There are rulesets like the https://github.com/shabanzd/debian_dependency_bazelizer which lets you depend on pre-built binary distributions. This avoids some of that hassle and is more hermetic. You do want to stop traversing transitive dependencies at some point so you don't pull in glibc and end up with an unportable binary. Another downside is that you lose cross build / cross platform capability.

A fully hermetic build is definitely possible (and desirable). There are fully hermetic compiler toolchains (e.g. https://github.com/bazel-contrib/toolchains_llvm) and libraries pulled from the BCR are generally hermetic. This lets you have fully deterministic builds that will produce the same result byte for byte on any machine.

So, just for fun. Let's assume we would like to keep the default for Linux for all users to depend on libacl, what would be necessary to make the build hermetic?

Someone would need to create a libacl BCR module for Bzlmod builds and a libacl.BUILD for Workspace builds. Both entail translating https://github.com/philips/acl/blob/master/libacl/Makefile (*) to a (set of) cc_library in a BUILD file.

This is entirely possible, and people create new BCR modules for C libraries every day (https://github.com/bazelbuild/bazel-central-registry/pulls?q=is%3Apr+is%3Aclosed)

The catch is that you will need to "Bazelize" any dependencies that libacl has first so that it can depend on them.

*) this seems to be some very old copy. the current one is at https://git.savannah.nongnu.org/cgit/acl.git/tree/ / https://download-mirror.savannah.gnu.org/releases/acl/acl-2.3.2.tar.xz.

Yeah FWIW we deal with this problem by patching in our own libacl dependency when fetching the repository. A bit messy. I'd be happy about removing that patch.