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