[question] CCI's area of influence from the perspective of OS architecture

[Nipheris]

Hello, Conan Team!

After having some thoughts regarding how many libraries and components of applications and operating system can be packaged and delivered by Conan, and included in CCI, I understood that I have no clear idea where Conan overlords drew a boundary for what should be considered "application-level" libraries and what should be considered "system library", or to be more accurate, "system API".

Let me give an example. Recently I have studied a recipe of openal and the recent fixes in it, and was suprised that it depends on libalsa library package (on Linux systems, of course). While it is a correct statement in itself, it is weird to see that libalsa as CCI package at all - because it is considered as OS-provided library API (see https://www.alsa-project.org/alsa-doc/alsa-lib/ ). In other words, libalsa (or libasound) should be in system_libs, just like winmm or ole32 for Windows.

So, here we have a question I personally doesn't have an answer to: what should be considered as provided by OS or provided by CCI as a package? There are the options I can propose:

• CCI should cover all the "userspace" libraries, even the ones that are considered "userspace API of operating system" - in this case every application that uses Conan can completely satisfy all the dependencies up to specific kernel-level API (and in this case we continue to depend on libalsa package on Linux systems), of course with exclusion of proprietary userspace components like winmm on Windows; the dependency tree is single and is not divided by the OS API layers;
• CCI should NOT include the libraries that are considered "userspace API of OS", or, at least, other packages like openal should NOT depend on such packages, but include the library in system_libs instead;
• CCI should include both types of the packages (that are considered "userspace API" and all the other "regular" libraries), but instead of making a direct dependency on API-libraries (like openal depends on libalsa) the packages should depend on special API-describing packages like it was done in Vcpkg for OpenGL - such packages should not contain any binaries, only just some "glue" logic in recipe to use system-provided headers and/or libraries.

I think it is crucial to make a decision beforehand, to have clean and well-designed dependency trees.

[uilianries]

Hi @Nipheris! Your question is vary valid and we are studying the best approach, there are pros and cons depending the approach. For instance, we can't track system library, it can vary according Linux distro and it's hard to replicate a scenario. We have a discussion about how to deal with system libraries here: #641

It would be great having your thought there. Regards.

[jgsogo]

opengl recipe with a system approach has been out for a while: https://github.com/conan-io/conan-center-index/blob/master/recipes/opengl/all/conanfile.py, no big issues so far and it is been consumed by some other packages.

I suppose that we cannot stop the community from trying to compile everything from sources... on the other hand, this ***/system recipes should be the way to go to unblock some dependencies.

[Nipheris]

@jgsogo Thanks for the link, seems ***/system-packages is a working and recommended approach to wrap API of operating systems in a cross-platform way, I am watching on this recipe for a while.

Maybe we should add some guidelines in wiki for this? OS userspace API boundaries are important IMO, I think Conan dependency graph edges should not cross such boundaries. For example, it will lead to a problems if some high-level userspace library like pulseaudio depends on libalsa instead of some system-package like alsa/system.

[ericLemanissier]

the situation already happens for xorg/system, as I signaled in #1605 (comment):

when installing xorg-dev system package, it installs the following packages, which are already on CCI (non exhaustive list):
libboost-filesystem1.65.1 libboost-system1.65.1 libfontconfig1 libfontconfig1-dev libfontenc-dev libfontenc1 libfreetype6 libfreetype6-dev
Isn't there a risk that a recipe requiring xorg/system and any of the libs listed above as a conan package (eg fontconfig/2.13.91) ends up linking two incompatible versions of the same library ? (qt is an example of such project, requiring directly both xorg, fontconfig and freetype)

I am thinking of two specific issues, which don't happen if the libraries just happen to be installed on system: if a package depends on xorg/system, one of the xorg libs will try to load system fontconfig (for example). what happens if the file name of the system fontconfig library is not the same as conan fontconfig package ? Also, won't the system fontconfig be always chosen, because it is present in the library's rpath ?

[jgsogo]

Yes, that's the big issue with this kind of system recipes. I'm not sure if @SSE4 or @czoido can add some more light here.

I can imagine two valid approaches:

1. whenever a system recipe installs something available in CCI, we should split that system recipe (those provided in CCI and those not) and move the boundary a little bit closer to the OS.
2. feature provides ([feat] Recipes declare what they provide (and this can create a conflict) conan#7337) can help with this issue. If the system recipe declares everything that it provides, Conan will generate a conflict if the CCI-package is used somewhere else in the graph. The only way to fix this error would be to (see option 1 above).