xkbcommon conan package

[ericLemanissier]

Hi,

We are currently working on a conan package for xkbcommon,to include it in Conan Center Index so that it is available for all conan users by default. We are at the crossroads where we need to decide between the 2 following implementations:

1. Either we make it a first class package, which means conan downloads the sources and builds xkbcommon itself
2. Either we make it a system package, which means the package is just a proxy for whatever version is provided by the system package manager (apt, pacman, yum, zypper etc.)

1 is the default strategy which gives the user the possibility to choose the version of the library he needs to consume, gives independence on the distribution provider, does not require privilege etc.
2 is used for specific "low level" packages for which there is a risk of conflict if the user install a different version that the system provided library. This is used for xorg, opengl and glu for example.

@bluetech @fooishbar do you think that there is a risk of conflict/incompatibility if a program links (at compile time or run time) to a custom build of xkbcommon (not provided by system package manager) ? Which of the option above would be the more relevant according to you ?

more details on the "system vs regular packages" topic on conan-io/conan-center-index#641
also, a "regular" xkbcommon conan package was implemented https://github.com/bincrafters/conan-xkbcommon and used by qt for several month without problems reported.

[bluetech]

Hi @ericLemanissier, this work looks nice!

do you think that there is a risk of conflict/incompatibility if a program links (at compile time or run time) to a custom build of xkbcommon (not provided by system package manager) ?

I can think of the following issues, you can consider whether they affect you:

• The Conan-compiled version might be configured differently from the system version. In particular, the paths and defaults (see meson_options.txt).

• libxkbcommon has 3 different shared objects, libxkbcommon, libxkbcommon-x11 and libxkbregistry. If there is some circumstances where they are used by the application but come from different versions, things might break. Not necessarily or even likely, but it's just something we don't support.

Which of the option above would be the more relevant according to you ?

I think it depends on the use case. I'm not familiar what how Conan is used so I can't really say which is more relevant.

Generally libxkbcommon is a stable library, the symbols are versions, and I don't anticipate any breaking changes in the future. But it does add new symbols, which might not be available on old system versions.

It has a wide distribution, being the dependency of many other packages, such as Wayland compositors & clients, Qt5 (also on X) and others, but it is not universal like libz or such.

Since you mentioned qt, you might be interested that they used to vendor libxkbcommon optionally, then switched exclusively to the system version: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=c3a963da1f9e7b1d37e63eedded61da4fbdaaf9a. But that's a different circumstance than a package manager I suppose.

[Croydon]

@bluetech Thanks for your reply

I'm interpreting your answer as an case for a regular Conan package, where Conan itself ships xkbcommon (instead of just calling some other system package manager).

libxkbcommon has 3 different shared objects, libxkbcommon, libxkbcommon-x11 and libxkbregistry. If there is some circumstances where they are used by the application but come from different versions, things might break. Not necessarily or even likely, but it's just something we don't support.

A Conan package would ship all three objects in the same package, meaning within a Conan build all three come from the same version

The question is more about severe conflicts, specifically at the runtime of libraries and applications depending on them.

Example OpenGL:
Most target environments either already have their graphical drivers or aren't supposed to be graphical to begin with. If Conan ships it's own OpenGL driver and other Conan libraries will link against it and those libraries are getting shipped to their target environments, then we are getting massive conflicts between those different OpenGL drivers at runtime. We actually tried that for a while (in an effort of getting rid of system packages), but this isn't doable.

Now we have an opengl/system package which tries to use the target environment's driver instead of building and shipping an own driver and this works much better.

System packages have their own disadvantages, like you can't be universal sure what version of libraries you get, with what build options their were build etc. That is why we try to avoid them and ship as much via Conan as we possible can. Just that some things are too low-level for this, like OpenGL and X11 for instance.

The essential question here is were xkbcommon falls in this schema.

[bluetech]

Right, libxkbcommon doesn't have requirements like the graphic libs.

libxkbcommon interacts with the system in the following ways I can think of, otherwise it is just pure input-output:

1. Reads the system XKB (xkeyboard-config) files. Unlikely to be an issue given other compat constraints there.
2. Reads the system Compose (libX11) files. Unlikely to be an issue given other compat constraints there.
3. On X, xkbcommon-x11 interacts with the X server. This is a stable interface, not an issue.
4. On Wayland, clients and compositors exchange keymaps in the XKB format generated by libxkbcommon. The format is stable, but not necessarily forward-compatible, i.e. we might introduce some extension that older versions are not able to read. Unlikely to be a problem however.

[ericLemanissier]

Thank you very much for your answers. conan-io/conan-center-index#2157 is now merged, we went down the "regular" conan package road. Xkcommon is now available on conan center index: https://conan.io/center/xkbcommon/0.10.0/?user=_&channel=_