Draft: testing/xlibre-xserver: new aport

Xorg development continues with xlibre, fork of the most active developer of 2024.

Due all the changes this is to be considered a beta version.

You do realise it's never getting merged in Alpine, right? You were there at the discussion with @ariadne and I think Ariadne was pretty clear, yet you opened the MR? (relevant discussion 2025-06-20 17:18+): https://irclogs.alpinelinux.org/%23alpine-devel-2025-06.log

I do not know maybe others do not hate this.
I am not sure how things work in these cases and who are the devs.

I thought that this can be useful for users that want to test it.

Software that is [actually being maintained] is software that "represents an unacceptable ideology"? This seems a weird view of software that can only negatively affect users. Can someone help me see this from Ariadne's point of view?

It's open source. It doesn't matter exactly who is doing the work — they don't control it. There's no fair reason to block it just because politically motivated reactionaries are doing a good job that benefits everyone.

However, the issue of control is what caused the fork in the first place. Taking the questionable worldview of those who created the fork into account while ignoring the harmful intentions of the business that deliberately killed the project is a perfect example of doublethink.

Canceling people simply because you disagree with their views—especially when their contributions are valuable—isn't a principled stance. It's selective outrage that undermines the openness and resilience of open source communities.

In the end, code is just code. The moment there is politics inside the actual code, I'm pro not merging it or patching the politics out (it's open source after all). I mean, Linux itself has had political issues in recent times, as did many other open source projects, but let's not go there.

IMO, better to have the option to use a maintained version of Xorg than just one full of issues and effectively dead.

And as someone who daily drives Alpine Linux, it would be very sad to see outside politics influencing what should be a technical decision.

added label

It is a technical decision.

The technical reason is that the security team does not have the bandwidth to provide lifecycle maintenance for multiple X server implementations. Part of the reason for moving X from main to community was to reduce the burden on the security team for long-term maintenance of X. Additionally, nobody so far on the security team has expressed any interest in collaborating with Xlibre on security concerns.

We have a working relationship with Freedesktop already, while we would have to start from the beginning with Xlibre.

Why does nobody on the security team have any interest in collaboration with Xlibre? Well, speaking for myself only here -- when I looked at their official chat linked in their README, I was immediately greeted with alt-right propaganda rather than tactically useful information about Xlibre development. At least for me, I don't have any interest in filtering through hyperbolic political discussions to find out about CVEs and other relevant data for managing the security lifecycle of X.

Without relevant security data products from Xlibre, as well as a professionally-behaving security contact, it is unlikely for Xlibre to gain traction in any serious distribution, because X is literally one of the more complex stacks of software for a security team to manage already.

At the same time, I sympathize with the need to keep X alive and in good shape, and agree that there hasn't been much movement from freedesktop in maintaining X in the past few years. There are many desktop environments which will never get ported to Wayland and we do need a viable solution to keep those desktop environments working.

closed

locked the discussion in this merge request