[question] Approach for system requirements

There are some recipes that may need to install tools that can be considered as system requirements.

There are already some recipes in the index that check for system tools installed but do not install them. Others like libusb do install system requirements as libudev.

We feel it is intrusive and risky to install system requirements when using a Conan dependency and we want to avoid this in Conan (specially asking for sudo permissions 😩).

The question here is what approach should be taken when packaging recipes that require any kind os system requirement:

• Should we create recipes for system requirements and package binaries?
• Should we just check the existence of that tools installed and just raise?
• Should we create “proxy recipes” that perform those install or checks to model that dependency in the conan graph?

Feedback please!

[SSE4]

for the reference, I am copying here problems/disadvantages/limitations caused by system requirements we previously faced on bincrafters:

---

System Requirements in conan known to cause lots of various issues, they are hard to maintain, and don’t scale well. some problems with System Requirements:

• they require running system package manager from sudo, which is not a desired in many cases. they pollute build machine, they require user interaction, and they require permissions which developer might not have at all.
• system requirements don’t support cross-building at all, especially cases like cross-compiling from Windows/Mac to Linux are impossible, and even Linux -> Linux is problematic.
• due to the fragmentation, there are many major package managers to support, like yum, apt, pacman, etc. support of each new package manager requires additional baby-sitting (and possibly modifications to the conan itself, to add new distributions like Gentoo, Slackware, etc.)
• within single package manager, there are various architectures to support - and this adds an additional level of scalability problem.
• even within single package manager, various distributions may have different names of packages. for instance, Fedora, RHEL and CentOS are known to have different package names for certain packages.
• even within single distro, packages are deprecated and removed from time to time, so it requires continuous maintenance with every new release.
• the code to use system package manager in recipes looks ugly - it has lots of nested conditions.
• due to the various bugs in distributions, packages often conflict with each other, making it impossible to build a conan package on the system. for instance, on Ubuntu, 32-bit python-development package conflicts with 64-bit one.
• installing additional software from system package manager, may confuse conan build. for instance, libprotobuf-dev might be installed as a dependency of some other package, then it may override protoc executable from the conan package, which is not a desired effect.
• builds are no longer truly reproducible, because various distros have different versions of system packages, therefore behaviour may change after recompiling on another distro.
• additional point of failure and additional dependency on the availability of system package manager registry - e.g. apt repositories are known to have downtimes. given the fact conan builds on CI are very unstable for other reason, it would be nice to have to remove that factor.
• conan builds are no longer self-contained - installation of executables/libraries will not run or link because of dependency of system libraries, which might not be available on another machine.
• use-case simply doesn’t work on systems with no system package managers (e.g. source-only distros, like LFS systems), or systems with poor support for package managers or lack of packages (e.g. Windows).
• in order to use conan package, now it’s needed to use pkg-config to locate system requirements (or locate them by other means, some system requirements don’t even have .pc files!) - this adds additional complexity to the integration of conan package into the build system.

right now, the following conan packages are heavily based on system requirements:

OpenGL-related: GLU, GLUT, GLEW, GLFW, GLM, etc. ffmpeg: X11, vaapi, vdpau SDL2: X11, wayland, mir, audio APIs (pulseaudio, alsa, esound, nas, jack, etc.) wxWidgets: GTK

[SSE4]

my two cents:

Should we create recipes for system requirements and package binaries?

if it’s easy and straightforward - yes, that should be the first choice (as we did with libalsa, for instance)

Should we just check the existence of that tools installed and just raise?

I’d say that’s much better than system requirements, and should be the second choice

Should we create “proxy recipes” that perform those install or checks to model that dependency in the conan graph?

such things sometimes are needed, e.g. OpenGL support might be abstracted away in conan (on Windows, you have to link with opengl32.lib, on Mac you have to link with OpenGL.framework, and on Linux you need some system libraries such as libGL.so). this also applies to few other things which are system-specific (e.g. Python, OpenCL, Vulkan, CUDA, etc.). it would be much simpler for other recipes to just include opengl-support conan package and don’t worry about system specifics and system requirements. in such case, we delegate all baby-sitting and complexity to single recipe, rather copying ugly fragile conditions to every recipe which requires OpenGL.