Hi Fabio Package xlibre-server https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=xlibre-server does have this for 'conflicts' and 'provides': - conflicts=('xorg-server' 'nvidia-utils<=331.20' 'glamor-egl' 'xf86-video-modesetting') - provides=('X-ABI-VIDEODRV_VERSION=28.0' 'X-ABI-XINPUT_VERSION=26.0' 'X-ABI-EXTENSION_VERSION=11.0' 'x-server') So it conflicts with 'xorg-server', but does not provide it. This effectively breaks all packages that require / depend on xorg-server. And there are many of those of course. Our devs have tried to convince the maintainer to correct this, but he does not want to fix it. Also, the correct package name is not xlibre-server but xlibre-xserver, as can be seen via url https://github.com/X11Libre/xserver/releases/tag/xlibre-xserver-25.0.0.8, but the maintainer also does not agree with us. This is from the AUR xlibre-xserver PKGBUILD we provided, with the correct name, and 'xorg-server' included in the 'provides' array: provides=('xorg-server' 'X-ABI-VIDEODRV_VERSION=28.0' 'X-ABI-XINPUT_VERSION=26.0' 'X-ABI-EXTENSION_VERSION=11.0' 'x-server') On 8/14/25 18:05, Muflone wrote:

Hi artist

Il 12/08/25 11:26, artist ha scritto:

...

You have deleted the official upstream Xlibre's xlibre-xserver repository, in favor of xlibre-server while the latter is known to cause problems for users and is named incorrectly. This is harmful to the Arch Xlibre users and to the Xlibre project.

xlibre

On 8/12/25 00:21, notify@aur.archlinux.org wrote:

...

Muflone [1] deleted xlibre-xserver [2].

Do you have a clear, well defined, list of TECHNICAL issues the xlibre-server maintainer should solve ?

Please no vague, useless arguments like he's harmful, he's damaging the project, bad packaging, bad something, this is out of scope and I don't care at all about this type of opinions.

If you have such list, then please write it here and let me evaluate if those arguments are valid and if the current maintainer is ignoring without reasons. Let's compare the current PKGBUILD with your PKGBUILD changes.

Also please avoid to drag the discussion over previous reddit, telegram, forum, comments posts/discussions, I don't care at all about the Xlibre politics, please keep the argument on PKGBUILD issues only.

No others points will be considered.

Best regards

Hello again, | Does XLibre provide a compatible Xorg server implementation? Yes, the Xlibre xserver implementation is working completely backwards compatible with the Xorg server implementation. Any exception that is reported is treated as a bug, which needs to be fixed asap. | 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. | Is there a transparent transition path, uninstalling xorg-server and installing xlibre-server and everything will work like before? Yes, in our AUR xlibre-xserver packages there was transition path documented similar to https://github.com/X11Libre/pkgbuilds-arch-based. This procedure has been successfully run by many users, without any known issues. | 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 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 could be forced by using 'replace' clauses but afaik that is now allowed by AUR rules, and our view is that users should be able to transition from Xorg to Xlibre with minimum effort and without breaking existing packages and functionality. And that it should also be possible to transition back for testing and comparing, or any other reason a user might have. On 8/14/25 19:38, Muflone wrote:

Does XLibre provide a compatible Xorg server implementation?

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?

Is there a transparent transition path, uninstalling xorg-server and installing xlibre-server and everything will work like before?

What will happen if a user keeps xf86-* or xorg-* packages from the official repositories along with xlibre-server?

Hi again | Hola | | > | 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. | > | 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. 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. | > 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 the above doubts. | | Best regards | | -- | Muflone Best regards, artist On 8/14/25 23:25, Muflone wrote:

Hola

...

| 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  ?

...

| 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?

...

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.

Please clarify the above doubts.

Best regards

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

Hi Fabio I saw vitaliikuzhdin's respons to you comment on the xlibre-server package and there seems to be a misunderstanding. ABI versions exist for a reason and so do in some cases ABI incompatibilies. We do eliminate the ones we can by updating the code but of course for closed source drivers like the ones from Nvidia we depend on the vendor. We are trying to get Nvidia to update these versions in their drivers but that does takes time. Of course we want to prevent problems for Nvidia users in the mean time, and on other distributions we do this by adding this simple message to the installer:    Closed source drivers - like those from Nvidia - might not yet have an updated ABI version to match xlibre-xserver.    To prevent problems with these drivers create this file:       /etc/X11/xorg.conf.d/xlibre.conf       Section "ServerFlags"           Option "IgnoreABI" "true"       EndSection So this problem can be prevented and even when it does occur it's simple to fix it. Also a new Xlibre version cannot solve or prevent all incompatible ABI version issues, some versions actually have ncompatible code, so waiting for a new xlibre releaae is not a fix. All in all there is no reason to state that xlibre-server does not 'provide' the xorg-server compatible code. If this can be added to the PKGBUILD that would help users a lot and enable xlibre to collaborate and co-maintain as offered. Regards, artist On 8/15/25 14:36, artist wrote:

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

Greetings, Thank you for organizing a place for us to discuss these issues. My points are: 1. My primary reason for not providing Xorg was the extra configuration required, especially with Nvidia cards. Usually, I would expect Arch packages that claim `provides` to be a full drop-in replacement. That is, when I `pacman -U` the new packages to replace the old ones, everything should work out of the box (perhaps not optimally without proper configuration, but at least without crashes). Otherwise, this breaks non-interactive installations (goodbye, pipelines and builds in a clean chroot) and causes many bug reports from users who would not read the post-installation instructions (although I agree they absolutely should). 2. Mixing XLibre and Xf86 packages is not possible, as there are virtual `provides`/`conflicts` that prevent it. For example, `xf86-video-*` conflicts with `X-ABI-VIDEODRV_VERSION<25.0` and `X-ABI-VIDEODRV_VERSION>=26`, while `xorg-server` provides `X-ABI-VIDEODRV_VERSION=25.2`. On the other hand, `xlibre-video-*` conflicts with `X-ABI-VIDEODRV_VERSION<28.0` and `X-ABI-VIDEODRV_VERSION>=29`, while `xlibre-server` provides `X-ABI-VIDEODRV_VERSION=28.0`. 3. There are some exceptions to the rule above. Specifically, internal split packages of XLibre and Xorg may be combined. This is not a problem for `xlibre-server{-xephyr,-xnest,-xvfb}`, as they have a hard dependency on the same version of `xlibre-server`. However, if `xlibre-server-common` and `xlibre-server-devel` provide their Xorg counterparts, this would allow mixing. To me, it is clear that `xlibre-server-devel` should not provide `xorg-server-devel`, and nothing would break without this `provides`. However, if `xlibre-server-common` does not provide `xorg-server-common`, some packages will fail to satisfy dependencies, most notably `xorg-xwayland`. This is expected, as XLibre has dropped XWayland entirely. Still, for many users, myself included, this creates an issue since some DEs like Plasma 6 depend on `xorg-xwayland`. I see three potential solutions: - Drop support for XWayland, since XLibre dropped it too. - Make `xlibre-server-common` provide `xorg-server-common` and brace for bug reports due to incompatibility. - Create something like `xlibre-xwayland` that pulls Xorg sources but depends on `xlibre-server-common`, since it is the only package with such a dependency. 4. I don’t see the logic behind the naming suggested by XLibre maintainers. The Xorg package on Arch was named `xorg-server`, but the new package should be `xlibre-xserver`? Where did the additional `x` come from? For the Xf86 packages the logic is entirely different: instead of replacing a word, `xlibre-` is simply prefixed. This seems inconsistent. My consistent naming makes installation simple, as it can be automated with a few `pacman -Q`s and `sed`s. I don’t see the benefit of changing things the way they are and breaking updates for many users if there is no clear advantage apart from matching the upstream name. Distro packages, especially in the AUR, don’t have to follow upstream naming, and, as expected, other distros running XLibre do not agree on a single name either. We would be better off following the Arch naming convention on Arch. 5. Once I see a clear solution to the `provides` issue, I will update the packages ASAP and will add `@xlibre` as a co-maintainer. The rest of the duplicate packages (`xlibre-xf86-*` and `xlibre-x*-bin`) should, of course, be deleted. P.S. I’m sorry for all the time and effort this has taken. I’m sure things would move faster and more smoothly if the PKGBUILD author at XLibre contacted me directly, since the only people I’ve heard from were not related to packaging and simply repeated the same arguments while unhelpfully calling me names. From my side, I apologize for not adding the `provides` sooner. Please understand that I only wanted to avoid breaking users’ X sessions, unlike some of the other reasons people have assumed. Best regards, Vitalii On Sun, Aug 17, 2025 at 4:38 PM Muflone <muflone@archlinux.org> wrote:

Hi everyone

Reading the whole discussion with artist (on aur-requests) and vitaliikuzhdin (on [1]) the main arguments seems only these two:

First argument:

...

Package xlibre-server https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=xlibre-server does have this for 'conflicts' and 'provides': - conflicts=('xorg-server' 'nvidia-utils<=331.20' 'glamor-egl' 'xf86-video-modesetting') - provides=('X-ABI-VIDEODRV_VERSION=28.0' 'X-ABI-XINPUT_VERSION=26.0' 'X-ABI-EXTENSION_VERSION=11.0' 'x-server')

vitaliikuzhdin in the AUR package xlibre-server web [2] explains he has removed the *provides* option in the PKGBUILD in order to avoid breakage with the existing packages, as xlibre-server **is not** fully compatible with xorg-server (the extra/xf86-* packages will not be compatible for example) so the users will experience issues by mixing those packages. This argument was also confirmed by artist on his side.

At the same time, removing *provides* but leaving *conflicts* will lead to having a package which cannot be installed along with xorg-server and thus breaking all the packages requiring it [2]

While this approach is technically working to build and install the xlibre-server package makes it not very usable, breaking any packages explicitly requiring a X server (see [2]), causing then, a breakage he was trying to prevent.

Anyone installing xlibre-server will have conflicts with those packages, forcing the users to remove them if they want to install xlibre-server.

In general way the *provides* option in PKGBUILD is used to specify what packages provide/offer the mentioned packages, it's not for specifying binary compatible replacements.

Indeed a lot of packages use *provides* to specify different implementations, not perfectly binary compatible with the mentioned packages:

- extra/mariadb provides mysql but it's not perfectly binary compatible with it, both have their differences and not fully interchangeable

- extra/dracut provides initramfs like mkinitcpio but they behave very differently and they are not even slightly compatible

- aur/nvidia-550xx-dmks provides nvidia which is not the same for the extra/nvidia package at all, also it's an older incompatible version

For this reasons I believe there's nothing wrong to add provides=('xorg-server') to xlibre-server package, even if XLibre cannot offer a complete binary compatible drop-in replacement for xorg-server package.

A good approach would be, of course, to inform the users how to complete the whole transition path [4], by installing the extra dependencies or by following instruction e.g. in the Wiki.

Second argument:

...

Also, the correct package name is not xlibre-server but xlibre-xserver, as can be seen via url https://github.com/X11Libre/xserver/releases/tag/xlibre-xserver-25.0.0.8,

...

but the maintainer also does not agree with us.

This argument could be simply fixed later by submitting a newer package and merging xlibre-server into xlibre-xserver.

However this newer package must be submitted by current xlibre-server maintainer only, any attempt to hijack the original maintainer will be rejected, as long the maintainer is properly updating the xlibre-server package and he will not abandon it or makes dangerous choices/abuses requiring a maintainer change (**this is not** the current situation).

Best regards

[1]: https://aur.archlinux.org/pkgbase/xlibre-server?O=10

[2]: https://aur.archlinux.org/pkgbase/xlibre-server?O=10#comment-1031168

[3]: https://archlinux.org/packages/extra/x86_64/xorg-server/

[4]: https://wiki.archlinux.org/title/Arch_package_guidelines

-- Muflone

Hi, My setup broke down, so I won’t be able to log into the AUR for a few weeks (months?) until I can replace it. Feel free to take ownership of my XLibre packages and rebase them if you like. Just please keep the bootstrap package instead of the broken pre-upgrade one (unless you find a better solution) and don’t mess with user-provided build flags unless necessary. I ask this because I actually want to use those packages myself. I’ll have to ask Muflone to handle the orphaning/merging since I can’t do it myself. Sorry, I know it’s annoying to move so many packages so often. Best regards, Vitalii On Sun, Aug 17, 2025 at 6:01 PM Muflone <muflone@archlinux.org> wrote:

Hi

...

1. My primary reason for not providing Xorg was the extra configuration required, especially with Nvidia cards. Usually, I would expect Arch packages that claim `provides` to be a full drop-in replacement. That is, when I `pacman -U` the new packages to replace the old ones, everything should work out of the box (perhaps not optimally without proper configuration, but at least without crashes). Otherwise, this breaks non-interactive installations (goodbye, pipelines and builds in a clean chroot) and causes many bug reports from users who would not read the post-installation instructions (although I agree they absolutely should).

2. Mixing XLibre and Xf86 packages is not possible, as there are virtual `provides`/`conflicts` that prevent it. For example, `xf86-video-*` conflicts with `X-ABI-VIDEODRV_VERSION<25.0` and `X-ABI-VIDEODRV_VERSION>=26`, while `xorg-server` provides `X-ABI-VIDEODRV_VERSION=25.2`. On the other hand, `xlibre-video-*` conflicts with `X-ABI-VIDEODRV_VERSION<28.0` and `X-ABI-VIDEODRV_VERSION>=29`, while `xlibre-server` provides `X-ABI-VIDEODRV_VERSION=28.0`.

These reported issues are software related, not packaging related.

artist himself confirmed XLibre and xf86-* package cannot be mixed and it's the main incompatibility reason

...

if `xlibre-server-common` does not provide `xorg-server-common`, some packages will fail to satisfy dependencies, most notably `xorg-xwayland`. This is expected, as XLibre has dropped XWayland entirely. Still, for many users, myself included, this creates an issue since some DEs like Plasma 6 depend on `xorg-xwayland`.

Also this one is a software related matter, coming from the option to use XLibre over Xorg, it's not a packaging thing and as packager there's nothing much you can do to fix, until you join the XLibre development team and discuss with them how to keep wayland working.

...

4. I don’t see the logic behind the naming suggested by XLibre maintainers. The Xorg package on Arch was named `xorg-server`, but the new package should be `xlibre-xserver`? Where did the additional `x` come from?

The extra 'x' comes from the author fantasy, it's not different than call the server with a different name like XLibre-pingpong

Regardless the author's decisions how to name their software, the downstream package should try hard to follow the author names, including changing the name if the author changes to something entirely different.

...

users if there is no clear advantage apart from matching the upstream name. Distro packages, especially in the AUR, don’t have to follow upstream naming, and, as expected, other distros running XLibre do not agree on a single name either. We would be better off following the Arch naming convention on Arch.

AUR packages should match the upstream name, by following also the Arch Packaging standards too.

Apart that, why shouldn't you follow their name? Only to keep the newer xlibre name as closing as possible the older xorg name? That's not a valid argument to me.

...

5. Once I see a clear solution to the `provides` issue, I will update the packages ASAP and will add `@xlibre` as a co-maintainer. The rest of the duplicate packages (`xlibre-xf86-*` and `xlibre-x*-bin`) should, of course, be deleted.

Thank you for understanding the situation and trying to improve the collaboration between authors and maintainers.

...

P.S. I’m sorry for all the time and effort this has taken. I’m sure things would move faster and more smoothly if the PKGBUILD author at XLibre contacted me directly, since the only people I’ve heard from were not related to packaging and simply repeated the same arguments while unhelpfully calling me names. From my side, I apologize for not adding the `provides` sooner. Please understand that I only wanted to avoid breaking users’ X sessions, unlike some of the other reasons people have assumed.

I've read a bit of extra discussions on different platforms and I'm not happy at all how the things were managed and how they tried to hijack the packages on AUR. For these reasons some xlibre packages were already deleted on AUR and xlibre-server is still still living in AUR, with the hope to find an agreement between the maintainer (vitaliikuzhdin) and the XLibre author (let's assume jcrowell is one of them).

Please, regardless how the things were managed in the past, let's avoid to drag the discussion on different arguments as they won't even help to find a resolution.

Thanks for you cooperation.

-- Muflone

Hi Vitalii and Muflone, On 8/20/25 14:01, Muflone wrote:

Hi Vitalii

...

Hi,

My setup broke down, so I won’t be able to log into the AUR for a few weeks (months?) until I can replace it. Feel free to take ownership of my XLibre packages and rebase them if you like. Just please keep the bootstrap package instead of the broken pre-upgrade one (unless you find a better solution) and don’t mess with user-provided build flags unless necessary. I ask this because I actually want to use those packages myself.

I'm sad to read your issues, take care about yourself and come back soon.

I'm also sorry to hear this and hope you can fix the problem soon.

...

I’ll have to ask Muflone to handle the orphaning/merging since I can’t do it myself. Sorry, I know it’s annoying to move so many packages so often.

After having verified this message authenticity with separated checks with Vitalii, I've added xlibre as co-maintainer for all the 32 xlibre-* packages so that artist could fix them and in the case, rename them (by pushing another package and filing a merge request) later.

I'm fine with taking care of the packages and any needed changes. I won't add or change build flags. To prevent any possible misunderstandings I will only make changes after having discussed these with Muflone.

@artist, please fix the packages with the provided advices and try to respect his desires while maintaining the xlibre packages

@Muflone, which changes shall I make? Please check and correct or remove where needed: - Update the 6 xlibre-xserver* packages to version 25.0.0.9 which we released half an hour ago. - Rename the 6 xlibre-server* packages to xlibre-xserver* using the create/merge procedure. For these the conflicts array will have to be expanded with the xlibre-server package name. - I'm quite unsure about the 'provides=xorg-server' addition. These should not be done yet, correct?

Thanks everyone for collaborating in obtaining the best solution possible.

Kind regards, artist