Right now Xwayland is built as part of xorg-server when the wayland use flag is present. Xwayland was released separately this march and will be used in the Fedora 34 release. For better wayland desktop support it would be good if it was possible to use this standalone Xwayland release. This would probably require to add virtual packages for Xwayland (so that other packages can depend on xorg-server[wayland] or xwayland) and installing Xwayland should probably block xorg-server[wayland]. Reproducible: Always Current release of Xwayland is 21.1.1: https://lists.x.org/archives/xorg-announce/2021-April/003082.html
A virtual is needed for competing implementations. In this case it should be sufficient to use something like RDEPEND="xwayland? (gui-libs/xwayland )" inside a revision bumpbed xorg-server ebuild. That way if xorg-server ever gets back on path of being released, we can just ship xwayland with it same as now. And if upstream ever officially kills off xorg-server 1.21, we will just switch any x11-base/xorg-server[xwayland] dependency directly to gui-libs/xwayland. Virtual provider never needed.
(In reply to Niklāvs Koļesņikovs from comment #1) > A virtual is needed for competing implementations. In this case it should be > sufficient to use something like RDEPEND="xwayland? (gui-libs/xwayland )" > inside a revision bumpbed xorg-server ebuild. That way if xorg-server ever > gets back on path of being released, we can just ship xwayland with it same > as now. And if upstream ever officially kills off xorg-server 1.21, we will > just switch any x11-base/xorg-server[xwayland] dependency directly to > gui-libs/xwayland. Virtual provider never needed. In this case we have the xwayland shipped with xorg-server and we have the standalone version. I would say they are competing. If I understand your suggestion correctly this would always pull in the external xwayland and never build the included version? Also maybe at some point, we might only want to have the x11-base/xwayland server and not pull in the xorg-server at all. Should other packages always depend on x11-base/xwayland directly to prevent pulling in the complete xorg-server? But then the user has to install the standalone xwayland and cannot use the xorg-server bundled xwayland server.
My understanding is that the stand alone Xwayland is merely a snapshot of part of the code ships with xorg-server - with the exception of slotted ebuilds we do not allow installing different versions of the same package at the same time, so this is perfectly consistent with that. The point is that I do not currently believe there's any kind of clarity from upstream on whether Xwayland being a separate release is just a blip or if it's being split out into its own project. Neither do we know if xorg-server will be seeing another release or if any other relevant sub-projects will be getting similar releases to Xwayland, which is why I proposed the Gentoo guidelines violating RDEPEND="xwayland? (gui-libs/xwayland )" inside a revision bumpbed xorg-server to ship newer Xwayland while upstream figures itself out. Since packages can keep depending on x11-base/xorg-server[wayland] and not care what actually provides Xwayland binary, Gentoo can relatively easily ship a newer release without changing many ebuilds (and risking doing that all over if xorg-server comes back to life), and the only one hurting will be our collective QA heart. Either way I do not see why or how introducing virtual/xwayland will help the situation in any way, since there are no competing implementations (that is, someone making Xfooland because they didn't like Xwayland).
(In reply to Niklāvs Koļesņikovs from comment #3) > My understanding is that the stand alone Xwayland is merely a snapshot of > part of the code ships with xorg-server - with the exception of slotted > ebuilds we do not allow installing different versions of the same package at > the same time, so this is perfectly consistent with that. agreed. > > The point is that I do not currently believe there's any kind of clarity > from upstream on whether Xwayland being a separate release is just a blip or > if it's being split out into its own project. Neither do we know if > xorg-server will be seeing another release or if any other relevant > sub-projects will be getting similar releases to Xwayland, which is why I > proposed the Gentoo guidelines violating RDEPEND="xwayland? > (gui-libs/xwayland )" inside a revision bumpbed xorg-server to ship newer > Xwayland while upstream figures itself out. Good pint > > Since packages can keep depending on x11-base/xorg-server[wayland] and not > care what actually provides Xwayland binary, Gentoo can relatively easily > ship a newer release without changing many ebuilds (and risking doing that > all over if xorg-server comes back to life), and the only one hurting will > be our collective QA heart. > > Either way I do not see why or how introducing virtual/xwayland will help > the situation in any way, since there are no competing implementations (that > is, someone making Xfooland because they didn't like Xwayland). I did some thinking and I think your solution is indeed better. I would suggest adding a use flag to switch between the external xwayland dependency and building the internal bundled Xwayland server (like "bundled-xwayland"). This use flag would be off by default and would block the seperate xwayland if enabled. This way it is still possible to switch implementations. What do you think?
Both xorg-server w/wayland and standalone, produce a named binary - Xwayland. Only one package is going to be able to put that binary down without portage complaining, unless you either change the name of one of the binaries or put it in another place than /usr/bin. So if you build standalone Xwayland, then you wouldn't want to build xorg-server with the wayland use flag, and anything checking against xorg-server[wayland] would fail
To add further to my last comment. I've been looking at both Xorg-server and Xwayland standalone. For xorg, there is a variable in meson, that you don't address in the ebuild option('xwayland-path', type: 'string', description: 'Directory containing Xwayland executable') That would get the xorg xwayland binary out of the way of the standalone. On the standalone side, they also have the xwayland_path option. The only thing is to make sure both meet these conditions, if both present. Their names must not be the same, in the same directory. in other words don't try and create /usr/libexec/Xwayland from both packages. The standalone package produces a .pc file for xwayland specifying where the binary is and what it's called. To keep things the way they are, I recommend, leaving xorg-server alone, this would put the binary in /usr/bin where it now resides. When/if you create xwayland-???.ebuild make sure that the xwayland_path is exposed and set for something like /usr/libexec/Xwayland. That keeps it out of the path of the original, and when apps should be able to find it with the .pc file. Just some thoughts.
One more (lol, yeah I know) comment I mentioned in the last comment that both xorg and standalone have an xwayland_path option, THAT IS INCORRECT, only the standalone has it. And for the standalone, I've looked in meson, as that's what I built my version with. xwayland_path is in the git for the master but not in the server-1.20 branch. And you might think about moving away from autotools to use meson, even for the xorg-server. They (xorg) are moving that way. I would not recommend autotools for xwayland, I'd meson straight from the beginning.
I don't think it will build with autotools, as it was stated in the release announcement, that it can only be built with meson. Regarding the duplicate Xwayland binary: It should suffice to block xorg-server with Xwayland binary (which would be blocking the xorg-server with walyand use flag). The solution I suggested in comment 4 would achieve this as well.
Created attachment 715308 [details] ebuild for standalone xwayland Adding this to create a standalone xwayland server. I have it under gui-apps/xwayland, my reasoning being it's an application of wayland (that happens to let X apps run).
Created attachment 715311 [details, diff] patch for standalone xwayland ebuild This patch throws away a couple of things that have been left hanging in the meson.build. It's stuff that Xorg puts down, Xserver.1 and protocol.txt, and really shouldn't be installed by the xwayland.
Things to note about the xwayland ebuild is that the binary goes in /usr/libexec. This is passed in from the ebuild OR the default /usr/bin is used (which would create a problem with xorg-server being installed). I was reading a conversation among the wayland people and their thought along with the path variable was that /usr/libexec would be a good place to put the binary. The standalone package produces a xwayland.pc that goes in pkgconfig dir. It has the path to the Xwayland binary in it along with some other vars. Mine --- Name: Xwayland Description: X Server for Wayland Version: 21.1.0 xwayland=/usr/libexec/Xwayland have_glamor=true have_eglstream=true have_initfd=true have_listenfd=true have_verbose=true --- Enjoy
It's not immediately apparent to me how kwin_wayland or mutter would know to use the Xwayland in libexec instead of the usual bin location but if that's achieved by each package detecting Xwayland via pkg-config and then being configured to launch that at build time, this is a no-go on many levels: 1. it would mean that a package having RDEPEND on xorg-server[wayland] would actually be depending on a completely different package 2. it assumes (possibly correctly) that all Xwayland users rely on build-time configuration via pkg-config rather than always trying /usr/bin/Xwayland first 3. if statement 2 is true, shouldn't the xorg-server[wayland] already have installed its own xwayland.pc, since build systems allegedly look for it? 4. Xwayland on PATH would not be the one actually being run ;( I'm sure there's more issues I might have missed. This doesn't mean I'm against having an Xwayland ebuild but it really should play nicely with the way Portage works and managed dependencies, rather than hacks around it.
And of course I remembered as soon as I replied: 5. from statement 4. it follows that there would be no way for a Gentoo user to know which Xwayland each of their packages is using other than looking at build times (among other issues). And should the user try to downgrade it would possibly cause a broken X11 fallback that might not be visible to revdep-rebuild or preserve-libs FEATURE. Am I missing something here? Judging by the comments and ebuild, I think I'm right but this this then is a total hack.
For xorg-server who knows if there will ever be another version. No one is stepping up for any type of release. Be that as it may. 1. For RDEPEND and xorg-server[wayland], and other packages, that's a choice for the developers to make, they're the ones that will have to modify all the other packages. It has nothing to do with me or the xwayland ebuild. 2. Not sure what you're talking about, but it doesn't seem to have anything to do with the xwayland ebuild itself. 3. same, except at the moment, xorg-server does not produce a .pc file for anything having to do with wayland. 4. Indeed, libexec isn't in the path so it wouldn't run, thus the pointers in the .pc file. As as side note wlroots, has an env var override for the the xwayland server, and with the newest versions it will use the .pc file. For Gnome, they ship the Xwayland standalone server, and I don't know what KDE is doing. 5. issue you're bringing up makes absolutely no sense. The ebuild and patch do play nice, and they play by portage rules. Not sure why you consider this a "hack"
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c5f13f25c3bc678b9a619a1757885d207c3a3277 commit c5f13f25c3bc678b9a619a1757885d207c3a3277 Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2021-06-22 21:22:30 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2021-06-22 21:26:40 +0000 x11-base/xwayland: new package. Closes: https://bugs.gentoo.org/785430 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> x11-base/xwayland/Manifest | 1 + ...xwayland-drop-redundantly-installed-files.patch | 27 ++++++++ x11-base/xwayland/metadata.xml | 16 +++++ x11-base/xwayland/xwayland-21.1.1.ebuild | 77 ++++++++++++++++++++++ 4 files changed, 121 insertions(+)
