I forgot to add; the xf86 packages from xorg and those from xlibre should conflict indirectly, based on the conflict for the respective ABI versions of xorg-server and xlibre-server. On 8/15/25 14:20, artist wrote:
Hi
On 8/15/25 14:03, Muflone wrote:
Hi
| > | Is it current latest tagged/released version 25.0.0.8 a compatible Xorg server able to run all the same packages as Arch Linux xorg-server package? | > Yes, the current Xlibre xserver 25.0.0.8 can run all the same packages and the Arch xorg-server packages. Exceptions here are also regarded as bugs. | | | So at the moment, you say, there are not such exceptions if xlibre-server provides xorg-server, both binaries and libraries are still compatible with a random client requiring ANY function from /usr/lib/xorg/modules/extensions/libglx.so ?
xlibre-xserver has, and uses, its own module path, to this becomes file /usr/lib/xorg/modules/xlibre-25.0/extensions/libglx.so Any xorg client, like for example glxgears, will use it and work as intended.
This is good, regardless the path/file change, it's important the libraries expose the same functions names and arguments.
| > | What will happen if a user keeps xf86-* or xorg-* packages from the official repositories along with xlibre-server? | > All xlibre-xserver AUR packages conflict with, and provide, the corresponding xorg-xserver packages. | > The same is true for the xf86 packages, for which the mentioned documentation also contains: | > "Build and install all xlibre packages of which the corresponding xorg one has been removed" | | A package with provides is meant to offer a compatible experience with the "provided" package, which seems not exactly the xlibre case. | | Installing for example xf86-video-intel would break or will xf86-video-intel package work properly with xlibre-server?
Xlibre not only provides the xlibre-xserver packages, but also all xlibre-xf86* input and video driver packages. These conflict with, and provide, their xorg xf86 counterpart packages.
These conflicts are not included in xlibre-server package, so at the actual state any user could keep both xlibre-server and xf86-video-* packages installed at the same time.
So, what would happen then to these users? Will their xf86-video-* package work or will them be incompatible with the current xlibre-server package?
These xf86-video-* packages will not work, as they are not built against the xlibre-server(-common/-devel) packages.
It is possible to add conflicts to the xlibre-xserver packages for the xorg xf86* drivers to prevent mixing xlibre packages with xorg server/driver ones.
There's not any xlibre-xserver package, don't confuse multiple things. At the actual state xlibre-server package has no such conflicts and therefore the user will have both xlibre + xf86 packages installed along.
The user can indeed have both xlibre and xf86 packages installed, which is not intended by the Xlibre project and will cause problems.
| > A similar message is shown by pacman while installing the package, using an install file: | > "It is required to replace all installed xf86* xorg driver packages with their xlibre-xf86* counterparts before starting xlibe-xsever. So if for example xf86-video-intel has been installed it should be replaced with xlibre-xf86-video-intel." | | This seems exactly the opposite of the above example of mine.
The Xlibre project has forked the xorg-server repo, and also all xf86-input/video driver repos as there are relationships between these. These are meant to be used together.
Please clarify again, could xlibre-server and extra/xf86-* packages live together in the same installation without any breakage?
No, this is not possible without causing breakages. We have discussed this possibility earlier in the project team and decided this would currently take too much work as not only the driver packages would need to get separate module paths, but also the config and wrapper files. And even then this would get very confusing for users which is not desired. So our intention is to give the users the possibility to install xlibre-server with (only) xlibre-xf86 packages, and the possibility to go back to xorg-server with (only) xf86 packages. This with a minimum of effort from the users, and without breaking any existing functionality.
Thanks again
You're welcome.
regards
artist