I believe this constitutes a breaking change when building runc, and we should address it with the following three improvements:

1. Explicitly specify the supported version range for the current libpathrs dependency.
2. Since libpathrs is already the default build tag, the system should automatically install it if missing — otherwise, both individual users and upstream maintainers will be forced to consult the installation documentation manually.
3. Add clear installation instructions for libpathrs to the README.md.
   @cyphar

@lifubang install automatically? That seems wrong, we don't do that with seccomp either, right?

That seems wrong, we don't do that with seccomp either, right?

The key difference here is that libseccomp is widely available in the default package repositories of most Linux distributions, making it straightforward for users to install via standard package managers. However, libpathrs has not yet been included in these distribution repositories, meaning users cannot easily install it through common package management commands.

This distinction justifies the need for automated installation support for libpathrs . While seccomp relies on existing distribution packages (and our documentation already covers its installation), libpathrs requires a more proactive approach to ensure users can build runc without manual, error-prone steps to locate and compile the dependency. Automating this process would address the accessibility gap and maintain consistency with the default-enabled build tag for libpathrs .

I'm fine with adding some more details to the README, but I'm really not in favour of installing libpathrs automatically as part of our build process. For one thing, it violates user expectations and would break within a fair few build systems (which disable network access to avoid build scripts downloading stuff from the internet).

At the moment libpathrs is only packaged for openSUSE but once runc has a soft requirement on it (in 1.5.0) every distribution will fairly create packages for it (it is a fairly low-dependency Rust project -- Debian already has all of the necessary dependencies packaged so even they shouldn't have too much trouble packaging it) and so the problem will resolve itself quite quickly IMHO. If we really want to provide a simple way to install libpathrs ourselves, (as discussed earlier in this thread) I plan to get OBS package builds for most distributions working soon and so we could point people to that repo until their distro provides packages for libpathrs. Either solution is better than running build-libpathrs.sh (which has a bunch of hacks to work within our CI and make release environments) on users' machines IMHO.

If containerd wants to upgrade to 1.5.0 after we release 1.5.0, their maintainers will need to install cargo and build libpathrs in their CI, or they could disable the libpathrs build tag, but currently the only way to do that is to manually specify another default tag, such as "seccomp".

@lifubang What if we move libpathrs to EXTRABUILDTAGS?

It's not perfect, not sure I like it now that I think about it more... The other option is to do the filter-out makefile thing. I think I've seen it in some PR already?

IMHO, having to specify seccomp doesn't seem too bad, though.

@kolyshkin suggested making modifying build-tags easier above, I opened #5165 to track that. I think putting it in EXTRA_BUILDTAGS is less than ideal because it means people setting additional build-tags would unset default ones -- this has been an issue in the past and so we should probably come up with a more robust solution (like the one @kolyshkin suggested).

I was able to use the script added in this PR and build runc for cri-o: cri-o/cri-o#9813