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 <[email protected]> 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
>
>
