Package Details: xlibre-xserver-devel 25.0.0.12-1

Git Clone URL: https://aur.archlinux.org/xlibre-xserver.git (read-only, click to copy)
Package Base: xlibre-xserver
Description: Development files for the XLibre X server
Upstream URL: https://github.com/x11libre/xserver
Licenses: MIT, ISC, X11, ICU, BSD-3-Clause, LicenseRef-Adobe-Display-PostScript, LicenseRef-DEC-3-Clause, HPND, LicenseRef-HPND-sell-MIT-disclaimer-xserver, HPND-sell-variant, MIT-open-group, NTP, SGI-B-2.0, SMLNJ, X11-distribute-modifications-variant
Groups: xlibre
Conflicts: xlibre-server-devel, xorg-server-devel
Provides: xlibre-server-devel, xorg-server-devel
Submitter: xlibre
Maintainer: xlibre (vitaliikuzhdin)
Last Packager: xlibre
Votes: 58
Popularity: 17.99
First Submitted: 2025-08-20 19:51 (UTC)
Last Updated: 2025-09-26 18:28 (UTC)

Required by (118)

Sources (3)

Pinned Comments

xlibre commented on 2025-08-25 11:26 (UTC) (edited on 2025-08-27 11:24 (UTC) by xlibre)

Building and installing xlibre-xserver to replace xorg-server
Attention

As during this procedure xorg-server is replaced with xlibre-xserver the running X-session - if being used - should not be stopped. As an alternative this procedure can be performed from a terminal session.

Notes
  • As the ABI versions of xlibre-xserver do not match those of xorg-server this first needs to be overcome by building and - temporarily - installing a bootstrap package.
  • The xf86-input/video driver packages will be uninstalled. Before starting the procedure make sure to query and store the names of these and install the respective xlibre-input/video drivers at the end of the procedure.
  • Some distributions have meta packages installed for input devices and video drivers. In case pacman reports a conflict with these make a note of their names and uninstall them.
Build and installation Procedure
  1. Build and install xlibre-xserver-bootstrap
  2. Build and install xlibre-input-libinput
  3. Build and install xlibre-xserver and confirm pacman's request to remove xlibre-xserver-bootstap
  4. Build and install the xlibre-input/video packages that correspond to the removed xf86-input/video ones
  5. Install any removed meta package again

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

jcrowell commented on 2025-08-03 10:31 (UTC) (edited on 2025-08-03 12:14 (UTC) by jcrowell)

I know all about depends/provides.. I've been using Arch for 20 years and used to maintain packages of my own and XLibre provides the same level of compatibility with the Nvidia driver that Xorg did, soon better. I don't need a lesson from you.

vitaliikuzhdin commented on 2025-08-03 10:23 (UTC)

@jcrowell,

We're removing the ABI check for the Nvidia proprietary driver. That fixes the problem you mention. It'll be in the next release.

...but not this release.

Your provides change didn't solve that issue. My ABI Ignore instructions did.

My provides do not claim to solve the issue. I removed the faulty provides to avoid claiming that there is no issue at all. The thing about provides on Arch is that they imply full and exact compatibility with the provided package. That is, if I install an XLibre component, the rest of the packages should continue to function and everything should work out of the box. If the user is required to make manual changes (like adding ABI Ignore flags), we can no longer specify provides. That is because they will not be strictly required to do so, as pacman cannot handle such situations, meaning most people won't do that and will end up with broken setups.

We're also moving the open video drivers directly into the xserver source tree so the ABI checks will no longer be necessary.

...in the next release.

Why would we need to satisfy you? The only reason we're even having to deal with you is because you squatted on our packages so quickly when we already had package maintainers. I'm one of the developers.

And I don't have to deal with you at all.

In any case, forward such discussions to the GitHub issue I have linked below.

jcrowell commented on 2025-08-03 09:51 (UTC) (edited on 2025-08-03 10:30 (UTC) by jcrowell)

@vitaliikuzhdin we're removing the ABI check for the Nvidia proprietary driver. That fixes the problem you mention. It'll be in the next release. Your provides change didn't solve that issue. The ABI Ignore instructions I got from NVidia and provided to the community did. What you did was make a mess. We have protocols/standards to follow that guarantee the display managers and display environments will continue to work because the functions they use don't change.

We're also moving the open video drivers directly in to the xserver source tree so the ABI checks will no longer be necessary. The only thing we can't do that to is the NVidia proprietary driver. You'll have to build from the xserver repo in the future to get updated video drivers.

Why would we need to satisfy you? The only reason we're even having to deal with you is because you squatted on our packages so quickly when we already had package maintainers.

Yes I'm one of the XLibre developers.

Have you read the thing you keep quoting?

"In constrast to Xorg (master - which probably won't see any release ever), we're taking special measures to keep compatibility with proprietary NVidia driver." - and all other drivers.

So we are fixing the ABI issues you as a package maintainer shouldn't have needed/tried to resolve. HaplessIdiot specifically tests the NVidia proprietary drivers before every release now because of the issues over the first few weeks.

This has nothing to do with Display Managers and Desktop Environments. They were never going to have compatibility issues. That was an issue you introduced with your incorrect fix.

vitaliikuzhdin commented on 2025-08-01 14:34 (UTC)

@jcrowell, to follow up on this: even if XLibre strives to resemble the original Xorg ABI as closely as possible, it is still not fully compatible, thus we cannot have the provides you want. A good chunk of the issues and the Wiki of the upstream are just people reporting issues with the Nvidia driver, which is also the primary reason for @xiota suggesting to remove the excessive provides in the discussion linked below. This is just one example.

I do, however, think I have a solution that would satisfy both of us. For context, this is not the first, and definitely not the last, experimental new project that claims to replace the older stable one. As an example, uutils-coreutils, a Rust rewrite of the standard Linux utilities, does not provide coreutils, even though some distros choose to act otherwise (similarly to how Artix did here). Anybody who is willing to take the risk can install a wrapper package with the necessary depends, provides, and symlinks.

For XLibre, there is already xlibre-is-xorg, and although it currently only features a wrapper for a single package, it would be really easy to add the rest. This way, the default is to have a proper stable setup, but users who choose to take and acknowledge the risk can just install the wrapper package and make the installation easier.

vitaliikuzhdin commented on 2025-08-01 06:48 (UTC)

@jcrowell, like I’ve already stated:

XLibre packages cannot provide their Xorg counterparts. The ABI versions have changed, meaning XLibre is not a drop-in replacement. Having it otherwise will result in broken systems and GUI sessions. I initially did this myself only because users would be reading the install instructions anyway, which required them to rebuild necessary components manually. However, now that there are discussions about adding XLibre to binary repositories, such provides/replaces must be removed. I agree it's inconvenient and I don’t enjoy the install process either, but for as long as there are several ABI versions, this trade-off is unavoidable. The author of the project has also made this clear: https://github.com/chaotic-aur/packages/issues/3684#issuecomment-3013197463

This is not up for discussion. I cannot list Xorg components under provides because users will end up with broken GUI sessions, report this package as the cause, and get it deleted from the AUR, since shipping packages that break systems (whether malicious or not) is obviously not allowed. I’m not even the one enforcing that. Please see the full discussion on GitHub if you'd like more context.

Also, you used "we", so I assume you're a project maintainer. This is the third (?) time I’ve had to quote the project author to a project maintainer. I’ve also already stated that I’m open to XLibre maintainers being co-maintainers here on the AUR.

Darukutsu commented on 2025-07-24 21:17 (UTC)

Recently had to switch back and forth between xlibre and x11 to check if something is bug.

## xlibre -> xorg
pacman -Qqs xlibre | sed -e 's/xlibre/xf86/' -e 's/xf86-server/xorg-server/' > x11.pacman && pacman -Qqs xlibre | sudo xargs pacman --noconfirm -Rdd && sudo xargs --noconfirm pacman -Syu < x11.pacman

## xorg -> xlibre
pacman -Slq | grep -E 'xorg-server|xf86-' | sed -e 's/xorg-server/xf86-server/' -e 's/xf86/xlibre/' > xlibre.pacman && pacman -Slq | grep -E 'xorg-server|xf86-' | sudo xargs pacman --noconfirm -Rdd && xargs yay --noconfirm -Sdd < xlibre.pacman

toxeia commented on 2025-07-21 15:56 (UTC) (edited on 2025-07-21 16:01 (UTC) by toxeia)

Sorry if this isn't the place to request assistance with this, but is there a way to configure pacman/yay to use alternative packages for dependencies? Specifically I'm struggling with plasma-workspace due to it wanting xorg-xwayland and xorg-server-common. Previously I uninstalled xlibre, let xorg reinstall, and then replaced xorg again but I'd like to avoid the hassle if it's possible.

Apologies - I read through the comments and found the mention of -Sdd being used, and used that to install plasma-workspace without the dependecies. Thank you.

ajgringo619 commented on 2025-07-06 18:33 (UTC)

OK, gotcha.

vitaliikuzhdin commented on 2025-07-06 10:45 (UTC)

@ajgringo619, I was talking about this:

I use yay -Sdd package_name so that any packages that I haven't converted to xlibre won't pull in xorg-server.

But if you do this only to packages that should depend on x-server rather than xorg-server, you should be fine.

« First ‹ Previous 1 2 3 4 5 Next › Last »