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