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