I think you have misunderstood that sentence. What I have been trying to say is that there should be no need for specific support for X11Libre from desktop environments because it should just work as a drop-in replacement, because the interfaces offered to desktop environments (not to modules/drivers) are backwards-compatible, so any desktop environment that works with X.Org should automatically work with X11Libre. (I wrote “should”, not “will”, because, as already mentioned, bugs may exist.)
As far as I can tell, the backwards (in)compatibility policies of X11Libre are not really any different from what used to be those of X.Org before they stopped doing major releases, shipping only 21.1.x point releases.
So my idea was to replace a project (X.Org) whose maintainers are busy trying to actively migrate all users off their project and to something else (Wayland) with a fork (X11Libre) that wants to continue X11 development where X.Org (in X11Libre’s view, and also in my view) dropped the ball. Replacing a dormant legacy project with an active drop-in replacement (often a fork of the original project) is usually done as a hard replacement with Obsoletes/Provides in Fedora. The migration from XFree86 to X.Org had been done that way, before we even had a formal Feature or Change process.
And the most recent examples of Changes replacing (without even changing the package name) packages with a purported drop-in replacement:
Both turned out to be not all that drop-in after all. For RpmSequoia, there was some messing with crypto policy configurations to make popular existing third-party repositories work. For wget2, someone has now packaged a wget1 separately. That did not prevent those Changes from being approved.
I am open to doing things differently, but my first idea was by default to attempt what in my view Fedora does by default in such a situation, trying to migrate all users by default.
None of this verbage is contrary to creating parallel installable packages. In fact that wget2 change proposal you reference supports what I’m asking you to consider as the least disruptive way forward for introducing an alternative implementation.
Looks to me with a quick koji search wget2 packages were being built for fedora all the way back to fedora 34. I can confirm on my mothballed f39 system that I just repowered for the first time in months that wget2 is available there. So the change proposal when it came in the f40 timeframe wasn’t a request for vaporware. Parallel user installable packages existed for multiple releases at the time of the change proposal.
You are putting the cart before the horse a bit here. Having an alternative X11 server implementation gestate as a parallel installable set of packages for 4 or 5 fedora releases before any systemwide change proposal was presented, following the wget2 example that you feel is an exemplar reference of how Fedora does things, would be the least disruptive path forward while still providing the alternative for users who care about it to configure, use and test.
Let me just suggest based on what ive seen of the 1200+ commits done on June 12, and the subsequent reversions of a subset of those. That is not the most significant issue ahead of this particular upstream.
As I understand it, that subdirectory was a deliberate change by upstream to allow for parallel installation of different versions. As it was worded in the social media post Lunduke made after interviewing Weigelt: “Per-ABI driver directories (allows distros installing multiple ABIs at the same time, eg. for smoother upgrades)”.
As a packager, I think this does not quite solve the parallel installability problem because the binaries in /usr/bin will still conflict (also with X.Org because even the Xorg binary has not been renamed) and hence force any parallel-shipped packages to use Conflicts instead of being parallel-installable. Unless the binaries are renamed by the package (which makes them no longer drop-in replacements) or put in some nonstandard directory.
For how many Fedora releases did X.Org X11 “gestate as a parallel installable set of packages” next to XFree86? Sorry, rhetorical question, I know the answer: zero.
Upstream has made their first stable release, there are approx. 4 months left until the Fedora 43 release, should be plenty of time to test and OK/NOK the change, but the Change process is such that the Change needs to be filed now to target Fedora 43.
That situation was very different: XFree86 created a licensing compliance problem and the XOrg fork was done to avoid that. That’s why XOrg’s X11 implementation replaced XFree86 in Fedora Core 2.
Yes, licensing changes on a codebase are always maximal disruptive because upstream projects seldom give significant notice concerning relicensing intent, causing everyone relying on the source to scramble. I would be overjoyed if an upstream project gave everybody a year’s notice on relicensing, but I’m not sure that has ever happened.
In this case, there is no such copyright licensing forcing function from upstream. In fact its clear from the code history here that the new fork owner was “incubating” a fork for several months in a dedicated branch containing the 1200+ refactor changes. This could have been a branded fork 4 months ago.
In fact after looking closer at some of the 1200+ commits in the forked codebase in scope of the change proposal, I’m concerned about potential copyright licensing problems inherent in some of the refactoring choices being made. The more I look at specific commits, the more concerned I’m becoming. But I’ll save the details for the formal change discussion, assuming the proposer doesn’t retract it and starts working on parallel installable packages.
I’m not sure I fully understand how this potential copyright licensing problems would go away if the proposal is redacted and replaced by a parallel installable packages instead?
Seriously? This moves 6 trivial 1-line macros and one 6-line macro (counting only the bodies, otherwise it is 1 1-line, 5 2-line, and 1 7-line macro) from one header file to a new header file with a possibly misleading copyright notice and SPDX declaration. It is not clear to me whether this tiny amount of mostly boilerplate code (do {…} while(0) pattern, delegating to another macro while defaulting some arguments) is even copyrightable at all. And the fix would be to get the copyright notice and the SPDX declaration on that new header file fixed, not to ban the whole project for such a tiny mistake.
I said I had concerns. I did not claim my concerns were unaddressable at the packager level.
And I’ll be more specific. I have concerns about the 1200+ commits that appear to have landed unreviewed around June 12th. Spot checking commits from the same person a year ago that did similar refactors appear to have respected original copyright and added copyright notices into files as needed as functions were refactored across files.
I can only speculate as to why the behavior changed with regard to transplanting copyright notices as part of the cut and paste of code refactors, but the change is a concern.
Is Xlibre going to keep up with CVEs for stable branches etc? like X.org CVEs come often, and the current X.org maintainers keep up with releasing them for distro consumption.
Apart from that, this fork is not something I think Fedora should touch with a barge pole, unless someone competent steps up to maintain it, Enrico is not competent enough to understand the X.org server design, and has constantly shown he misunderstands why the server is built like it is. I’d rather see someone write a from scratch rust X server than see x11libre in it’s current form being exposed anywhere near users..
Just because someone says they are maintaining something, doesn’t mean that thing is maintained.
remains to be seen, since this fork had its first “release” like yesterday there is no CVE history by which to judge correct action. I’ve not seem an specific intent documented.
It’s not even clear yet if anyone is going to bother filing CVEs against this codebase. First evidence of CVE handling indicates merging in commits to Xorg.. but over time I expect this to become harder to do as X11Libre drifts apart from Xorg.
I’m not sure what you’re referring to here. RPM used to build its own built-in OpenPGP handling, and then it was changed to compile against a different OpenPGP backend. No packages were replaced, it’s still the same “rpm”.
The official announcement for this change can be found here. This discussion thread falls outside of our official changes policy and process, and therefore will be closed. Please provide your feedback on the official Fedora changes thread linked, and ensure your discussion is inline with our Code of Conduct. Any comments made that are outside of our Code of Conduct rules will be removed.
As a reminder, the official change announcement is open to feedback for ~ 1 - 2 weeks and is announced by the Change Wrangler/Operations Architect (me). This is an established process that we do not deviate from in order to keep some kind of balance and control on the many changes that get proposed each release cycle. Once the community feedback period is over, the proposal then goes to FESCo who discuss and vote on the proposal. The official change proposal thread will then be closed after the FESCo vote concludes with the proposal outcome.
