For Fedora 40, the KDE SIG proposed the KDE Plasma 6 change which was accepted by FESCo.
As the KDE SIG team does not want nor has the capacity to maintain X11 support starting with KDE Plasma 6, we removed X11 support as detailed in the Fedora Change.
The following "new package" requests have been recently created to re-introduce X11 support replacement packages for KDE Plasma:
Re-introducing those packages will undo the work of the KDE SIG detailed in the above change proposal.
It will also effectively impose maintenance of those packages on the KDE SIG as we would be responsible for not breaking them when we do KDE Plasma updates, thus making those packages effectively our responsibility.
We understand that some users do not have alternative options to use Plasma 6 aside from using Plasma on X11.
Thus, the KDE SIG created a COPR of those KDE Plasma packages that tracks our packages in Fedora and rebuilds them with the X11 session subpackages automatically: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma6-x11-unsupported/
This provides a best-effort option for users that have no other options but to use X11, while explicitly marking those packages as unsupported and not binding the KDE SIG to guarantee that they work indefinitely.
We have documented this on the KDE SIG Wiki.
We are therefore requesting that those packages not be added to Fedora.
Timothée Ravier on behalf of the KDE SIG
Metadata Update from @ngompa: - Issue tagged with: meeting
At today's meeting, FESCo agreed to a preliminary injunction while we consider this issue. Until otherwise notified, these packages may not be re-admitted to Fedora.
These packages do not contravene any Fedora policy. In the discussion of the Change itself, the KDE SIG (in fact, the same person who has now filed this FESCo ticket!) has publicly stated that they have no power nor desire to prevent the introduction of those packages: https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/11
Timothée Ravier (@siosm) Packaging Team Sep 14, 2023 Kevin Kofler (@kkofler) Sep 14, 2023 I am also going to submit separate plasma-x11 (kwin-x11, plasma-workspace-x11, etc.) packages if the KDE SIG refuses to ship the subpackages, and I do not see how the KDE SIG wants to stop me from doing that We (the KDE SIG) certainly can’t stop you from doing that. The KDE SIG will simply not maintain those packages.
Timothée Ravier (@siosm) Packaging Team Sep 14, 2023
Kevin Kofler (@kkofler) Sep 14, 2023 I am also going to submit separate plasma-x11 (kwin-x11, plasma-workspace-x11, etc.) packages if the KDE SIG refuses to ship the subpackages, and I do not see how the KDE SIG wants to stop me from doing that
We (the KDE SIG) certainly can’t stop you from doing that. The KDE SIG will simply not maintain those packages.
The existence of this ticket blatantly contradicts the above statement.
As the KDE SIG team does not want nor has the capacity to maintain X11 support starting with KDE Plasma 6
The capacity is there. I have volunteered to maintain X11 support, and I know others have, too.
Re-introducing those packages does not undo any part of the Change proposal: Plasma will still be upgraded to Plasma 6, the -x11 packages are also both Plasma 6, and also, kwin-x11 and plasma-workspace-x11 will be obsoleted by the -wayland counterparts when the user initially upgrades to Fedora 40, as proven here: https://bugzilla.redhat.com/show_bug.cgi?id=2260793#c13
-x11
kwin-x11
plasma-workspace-x11
-wayland
Would you prefer these being packaged in a way that makes them completely independent of Plasma version bumps, using bundled (renamed, moved to a subdirectory, or statically linked) libraries? This is a lot more work, but it can probably be done.
We understand that some users do not have alternative options to use Plasma 6 aside from using Plasma on X11. Thus, the KDE SIG created a COPR of those KDE Plasma packages that tracks our packages in Fedora and rebuilds them with the X11 session subpackages automatically: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma6-x11-unsupported/ This provides a best-effort option for users that have no other options but to use X11, while explicitly marking those packages as unsupported and not binding the KDE SIG to guarantee that they work indefinitely.
The problem is exactly that. This is marked as "unsupported" and there is no guarantee whatsoever for how long these packages will remain available. Until the release of Plasma 6.0? 6.1? Until the release of Fedora 41? 42? Until the Fedora 40 EOL? Etc. Users who rely on Plasma on X11 need a guarantee that these packages will remain supported for as long as reasonably possible, which is probably years to come.
It shall be noted that the plasma6-x11-unsupported Copr's approach actually relies on the kwin and plasma-workspace packages maintaining a %bcond x11 0 with all the corresponding x11 conditionals all over the specfile, so it is that approach which requires the KDE SIG to actively maintain X11 support.
plasma6-x11-unsupported
kwin
plasma-workspace
%bcond x11 0
x11
My standalone packages, on the other hand, do not require any conditionals in the kwin and plasma-workspace packages, they will continue working even if the conditionals are dropped completely. So the KDE SIG does not have to maintain a single line of specfile to support it.
At today's meeting, FESCo agreed to a preliminary injunction while we consider this issue.
Did they really? In the meeting logs, I count nirik, sgallagh, conan_kudo, and dcantrell in favor of the resolution, that is only 4 +1 votes (of which only 2 actually wrote "+1"), 5 are needed to pass.
if you don't supported X11, fine. But you can't force us to use wayland , the question is, you want force the remove of X11 with a %bcond x11 0 , when X11 don't have any problem , neither gives you any extra work (is a false argument), just to force we to use wayland ? is ridiculous .
Another thing is KDE sig , seems KDE sig is a lot of people (https://src.fedoraproject.org/group/kde-sig ) and the decision have many people that support it when I think this is a decision of ngompa and maybe more one or two people. And many people said that are against it , much more than people that are in KDE sig .
To finish, I don't see what harm we can do when we build the x11 packages ?!?
IMO we should generally assume people can build whatever packages they like in Fedora, as long as they are legal and adhere to the packaging guidelines.
I've heard a lot of complaints along the lines of (not a direct quote) "you must move to Wayland because no one maintains X11!". Here are some people who are maintaining X11 packages, so let them do their thing.
IMO we should generally assume people can build whatever packages they like in Fedora, as long as they are legal and adhere to the packaging guidelines. I've heard a lot of complaints along the lines of (not a direct quote) "you must move to Wayland because no one maintains X11!". Here are some people who are maintaining X11 packages, so let them do their thing.
The only problem with this is, as those packages are external (stripped out) components from plasma 6, as we update our core packages, those two packages will essentially need to be kept in sync as well not to cause breakages for end users.
Essentially this would strongarm us into supporting X11.
I find it a bit uneasy that we tend to rationalize the removals with "nobody wants to maintain this" and when there is somebody who wants to do exactly that, we don't let them.
Let folks package the thing and feel free to ignore it. If you break it, they will fix it. And if (and only if) they cannot keep up, we can have a conversation about retiring the broken packages.
(I am not on FESCo, this is my personal opinion.)
My opinion (as a non-FESCo member) is the same as rjones: if there are people interested in maintaining the X11 support outside of the official Plasma deliverable, this should be allowed. Of course, that shouldn't mean that the KDE SIG needs to take on more work than they are willing - I think it's expected that it's the X11 maintainers that should bare the bulk of the workload.
I think not allowing the X11 support packages into Fedora would be similar to, let's say, refusing to allow the Pantheon desktop into Fedora since it uses the same underlying GNOME libraries - while strictly true that more components using GNOME libraries makes it harder for GNOME people (for me), it's all manageable with some communication. As a GNOME package maintainer, I am totally fine with doing the necessary communication so that Pantheon can at least attempt to stay in Fedora - but the expectation is that the Pantheon people would also need to put in work to stay up to date with GNOME changes.
Maybe in this case too the KDE SIG could send a note to Fedora-devel (or the KDE list) that a Plasma update is coming, and then the people interested in the X11 support can make sure their packages get rebuilt/updated for that? And failing that, the X11 support gets broken?
I think that this conversation deserves wider discussion than on a FESCo ticket and I have replied with my thoughts on the devel-list thread.
Let's have the conversation there, in public, and we can use this ticket for voting at the end.
These packages do not contravene any Fedora policy. In the discussion of the Change itself, the KDE SIG (in fact, the same person who has now filed this FESCo ticket!) has publicly stated that they have no power nor desire to prevent the introduction of those packages: https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/11 Timothée Ravier (@siosm) Packaging Team Sep 14, 2023 Kevin Kofler (@kkofler) Sep 14, 2023 I am also going to submit separate plasma-x11 (kwin-x11, plasma-workspace-x11, etc.) packages if the KDE SIG refuses to ship the subpackages, and I do not see how the KDE SIG wants to stop me from doing that We (the KDE SIG) certainly can’t stop you from doing that. The KDE SIG will simply not maintain those packages. The existence of this ticket blatantly contradicts the above statement.
Please, do not play this game. Those packages we are talking about (in their current form) are essentially strong forcing us into maintaining them.
If that wasn't the case, despite us disagreeing with you, we would accept them ( an this is despite knowing that we will get a lot of bad publicity when we reject support tickets because they will come from an X11 session...)
As the KDE SIG team does not want nor has the capacity to maintain X11 support starting with KDE Plasma 6 The capacity is there. I have volunteered to maintain X11 support, and I know others have, too.
Again, with the packages as they are right now, we will have to deal with all the upgrades and maintenance (or depend on you to take action before we continue with our upgrades)
It will also effectively impose maintenance of those packages on the KDE SIG as we would be responsible for not breaking them when we do KDE Plasma updates, thus making those packages effectively our responsibility. Would you prefer these being packaged in a way that makes them completely independent of Plasma version bumps, using bundled (renamed, moved to a subdirectory, or statically linked) libraries? This is a lot more work, but it can probably be done.
We would prefer not to have to (effectively) maintain those packages. Thanks :-)
We understand that some users do not have alternative options to use Plasma 6 aside from using Plasma on X11. Thus, the KDE SIG created a COPR of those KDE Plasma packages that tracks our packages in Fedora and rebuilds them with the X11 session subpackages automatically: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma6-x11-unsupported/ This provides a best-effort option for users that have no other options but to use X11, while explicitly marking those packages as unsupported and not binding the KDE SIG to guarantee that they work indefinitely. The problem is exactly that. This is marked as "unsupported" and there is no guarantee whatsoever for how long these packages will remain available. Until the release of Plasma 6.0? 6.1? Until the release of Fedora 41? 42? Until the Fedora 40 EOL? Etc. Users who rely on Plasma on X11 need a guarantee that these packages will remain supported for as long as reasonably possible, which is probably years to come.
This is intentional. We want to make it clear that the KDE Sig does not support X11. We are still human beings and we want to help others when we can.
It shall be noted that the plasma6-x11-unsupported Copr's approach actually relies on the kwin and plasma-workspace packages maintaining a %bcond x11 0 with all the corresponding x11 conditionals all over the specfile, so it is that approach which requires the KDE SIG to actively maintain X11 support. My standalone packages, on the other hand, do not require any conditionals in the kwin and plasma-workspace packages, they will continue working even if the conditionals are dropped completely. So the KDE SIG does not have to maintain a single line of specfile to support it.
Please, don't play this sort of game. We left that code purpose in case we had to revert back for emergency/critical reasons.
Now you want to use it against us? That is not very nice to be honest.
Don't play this game. You know full well this is a temporary situation until Fesco can deal with this ticket properly.
if you don't supported X11, fine. But you can't force us to use wayland , Don't confuse lack of support with forcing you to anything. the question is, you want force the remove of X11 with a %bcond x11 0 , when X11 don't have any problem , neither gives you any extra work (is a false argument), just to force we to use wayland ? is ridiculous .
if you don't supported X11, fine. But you can't force us to use wayland , Don't confuse lack of support with forcing you to anything.
the question is, you want force the remove of X11 with a %bcond x11 0 , when X11 don't have any problem , neither gives you any extra work (is a false argument), just to force we to use wayland ? is ridiculous .
Let's do simple math here. 2 types of sessions/technologies is more than 1, right?
And different kind of issues in different sessions means more work, right?
Thus why we don't want to maintain the X11 session.
As stated somewhere else, the packages in their current form essentially strong arm us into maintaining them.
Do NOT make this personal.
You haven't been involved in our discussions despite our meetings being absolutely open and everybody can join and participate.
We wrote the text of this ticket TOGETHER. Ngompa, Jgulrich, marcdeop,farchord, siosm, aleasto...
To reiterate myself: these packages right now force us to maintain them.
I would like to make something clear:
if the packages do not force on us extra work we will respect their inclusion (despite us being essentially against them).
(I wrote it in this other isolated comment because my previous one was like a mini-bible :sweat_smile: )
@marcdeop:
[The nested quotes are mine, the quoted replies are from @marcdeop.]
The existence of this ticket blatantly contradicts the above statement. Please, do not play this game. Those packages we are talking about (in their current form) are essentially strong forcing us into maintaining them.
I am not playing a game. I am doing exactly what I had said in September I would do. The KDE SIG has completely reversed its stance on those packages, now actively trying to prevent their introduction.
Would you prefer these being packaged in a way that makes them completely independent of Plasma version bumps, using bundled (renamed, moved to a subdirectory, or statically linked) libraries? This is a lot more work, but it can probably be done. We would prefer not to have to (effectively) maintain those packages. Thanks :-)
This could be workable. There are some concerns I have, such as various data files (QML scripts, icons, etc.) being potentially incompatible if I bundle or statically link the libraries and hope that is enough to avoid a hard-versioned dependency. (Sure, I could also ship a separate copy of all the data files, but then I need to patch the code to look for them in a different location.) But it is something we can try.
I also wonder how hard the version lock on the libraries really needs to be, i.e., whether, e.g., a kwin-x11 6.0.2 would actually work with kwin-libs 6.0.3 or even 6.1.0. (I know this is unsupported by upstream, which is why I have put in those version-locks in their current form.)
kwin-libs
The problem is exactly that. This is marked as "unsupported" and there is no guarantee whatsoever for how long these packages will remain available. Until the release of Plasma 6.0? 6.1? Until the release of Fedora 41? 42? Until the Fedora 40 EOL? Etc. Users who rely on Plasma on X11 need a guarantee that these packages will remain supported for as long as reasonably possible, which is probably years to come. This is intentional. We want to make it clear that the KDE Sig does not support X11. We are still human beings and we want to help others when we can.
But you still have not answered my question: For how long do you intend to maintain that kde6-x11-unsupported Copr?
kde6-x11-unsupported
I also think there is value in having the packages in Fedora proper rather than in a Copr.
But your kde6-x11-unsupported Copr also depends on those conditionals being present, which is not the same as "in case we had to revert back for emergency/critical reasons". If you ever remove those conditionals, the Copr will stop working instantly.
Where am I "playing a game"? My complaint is not that those conditionals exist, but that your Copr depends on them. The time window for "emergency/critical reasons" is going to close at or around the Fedora 40 release, at which point you will either be maintaining those conditionals exclusively for the Copr, or dropping both the conditionals and the Copr. (Or, technically, you could actually switch the Copr to my specfiles if you succeed at banning them from Fedora, which would be particularly funny. The specfiles are licensed under the MIT license under paragraph 3 of the FPCA, so you are of course free to use them.)
Did they really? In the meeting logs, I count nirik, sgallagh, conan_kudo, and dcantrell in favor of the resolution, that is only 4 +1 votes (of which only 2 actually wrote "+1"), 5 are needed to pass. Don't play this game. You know full well this is a temporary situation until Fesco can deal with this ticket properly.
I am simply contesting a vote that has not happened according to the FESCo voting rules clearly documented under: https://docs.fedoraproject.org/en-US/fesco/#meeting-votes
There were no explicit abstentions, so an absolute majority of the 9 FESCo members, i.e., 5 members, are needed to approve the injunction proposal. Only 4 actually did.
+1, I support the preliminary injunction.
We didn't have enough time in the meeting to properly discuss this issue, but I think we need to find alignment before the new packages are introduced. It sounds like there's a reasonable compromise position if they can be built without a version lock on KDE SIG.
I wrote:
There are some concerns I have, such as various data files (QML scripts, icons, etc.) being potentially incompatible if I bundle or statically link the libraries and hope that is enough to avoid a hard-versioned dependency. (Sure, I could also ship a separate copy of all the data files, but then I need to patch the code to look for them in a different location.) But it is something we can try.
PS: Also the decoration plugins, which are loaded into the KWin process. If I use a different libkwin and/or if my kwin-x11 does not match the KWin version expected by the plugins (especially plugins tend to be very picky on version numbers in Qt/KDE land), I presume I need to also move and bundle those plugins.
libkwin
And another question about the Copr: Have you (the KDE SIG) tested what will happen if: 1. I (the user) have F40 (with the official updates repository enabled, obviously) and your Copr installed, and 2. I have installed kwin-x11 and plasma-workspace-x11 from the Copr, and 3. you release a new Plasma version, and 4. I upgrade my system with DNF (or any GUI frontend to DNF)?
Will it upgrade kwin-x11 (and the other kwin* subpackages) to the new version from the Copr (assuming your automated scripts work and it gets built in time) or will it see the Obsoletes in the F40 updates packages and remove kwin-x11 instead (which is obviously not what I want)? Since you did not use an Epoch, I am not sure, though if the Copr packages (especially the kwin-wayland without the Obsoletes) mask the ones from the official updates repository somehow, it might work. Therefore, I am asking.
kwin*
kwin-wayland
(Note: In the previous paragraph, one can replace kwin with plasma-workspace to get the same question and, I assume, the same answer.)
In the event you have the copr enabled and you've explicitly installed the packages, they will overshadow the ones from the main distribution and be the only ones offered, due to the usage of repository priorities. Thus, you will not be switched back.
This can also be further strengthened by setting allow_vendor_change=False in /etc/dnf/dnf.conf if you wish to have absolute guarantee that packages will not ping-pong back and forth between Fedora and the COPR.
allow_vendor_change=False
/etc/dnf/dnf.conf
I would like to make something clear: if the packages do not force on us extra work we will respect their inclusion (despite us being essentially against them). (I wrote it in this other isolated comment because my previous one was like a mini-bible :sweat_smile: )
Of course we won't bring more work or at least we will avoid it as much as possible, in my opinion you will have more work in remove the x11 than to maintain it. And to be honest, perhaps what bothers me most is that I will have much more more work , of course I also think in the community which also lose
We won't have a FESCo meeting the next week (because of FOSDEM-related travel), so I unset the meeting tag. I think we can and should resolve this without waiting for the next meeting.
meeting
The discussion is still going on, but it seems that there's a lot of agreement, so we should be able to approve some resolution soon.
Metadata Update from @zbyszek: - Issue untagged with: meeting
Statement about the purported "compromise":
While I believe it is possible to package kwin-x11 and plasma-workspace-x11 in a way that it does not depend on libraries from the main kwin and plasma-workspace at all, I am not convinced that this is the best way to resolve this conflict, considering:
So, is it possible? Probably yes (and if that is the only way, I will have a try). Is it desirable? I am not convinced.
(EDIT: Clarified that we are talking about dependencies on the libraries, which imply a version lock. An unversioned Requires: plasma-workspace will definitely be needed because plasma-workspace-x11 is only going to ship startkde-x11 and not the whole plasma-workspace world, including libraries that many packages depend on. The kwin dependency might be possible to eliminate completely, though I guess we will still want it, e.g., for KCMs.)
Requires: plasma-workspace
startkde-x11
Statement about the purported "compromise": While I believe it is possible to package kwin-x11 and plasma-workspace-x11 in a way that it does not depend on libraries from the main kwin and plasma-workspace at all, I am not convinced that this is the best way to resolve this conflict, considering: user experience: My concern is that users will be unhappy and confused about the separate directories (and plugin types in the metadata) for KWin decoration plugins. It also means that upstream decorations built from source would no longer load in kwin-x11 unless patched. maintenance effort: I suspect that it will be a lot more work for us (me and whoever signs up to comaintain the -x11 packages with me) to ensure the duplicated code and data does not conflict than to just bump and rebuild the package whenever Plasma is bumped (as annoying as the latter admittedly is). I also suspect that the KDE SIG, too, will be left with more undesired bug reports about things such as file conflicts than with the current approach. So, is it possible? Probably yes (and if that is the only way, I will have a try)? Is it desirable? I am not convinced. (EDIT: Clarified that we are talking about dependencies on the libraries, which imply a version lock. An unversioned Requires: plasma-workspace will definitely be needed because plasma-workspace-x11 is only going to ship startkde-x11 and not the whole plasma-workspace world, including libraries that everything depends on. The kwin dependency might be possible to eliminate completely, though I guess we will still want it, e.g., for KCMs.)
So, is it possible? Probably yes (and if that is the only way, I will have a try)? Is it desirable? I am not convinced.
(EDIT: Clarified that we are talking about dependencies on the libraries, which imply a version lock. An unversioned Requires: plasma-workspace will definitely be needed because plasma-workspace-x11 is only going to ship startkde-x11 and not the whole plasma-workspace world, including libraries that everything depends on. The kwin dependency might be possible to eliminate completely, though I guess we will still want it, e.g., for KCMs.)
What if we look at it like an rpmfusion package?
For example, mesa-va-drivers-freeworld, when there'S a mesa update on Fedora, dnf will hold that update back until rpmfusion gets the -freeworld package updated (Because of dependancy requirements and whatnot).
Couldn't the -x11 packages work a bit like that? People using them would have to maybe wait "up-to" a week to get the update, but that's probably not a huge deal in the grand scheme of things right?
In fact, that is already the situation for, e.g., plasma-pk-updates, which the KDE SIG also refuses to support in any way (since they now ship the Discover updater on the spin instead), so they will typically not rebuild it for Plasma version bumps, even though all that is (was, in Plasma 5 land, at least) needed in that case is a simple rebuild. (Plasma 6 support is a different story, so I might have to drop plasma-pk-updates in F40, but it is still good as an example.)
plasma-pk-updates
Statement about the purported "compromise": While I believe it is possible to package kwin-x11 and plasma-workspace-x11 in a way that it does not depend on libraries from the main kwin and plasma-workspace at all, I am not convinced that this is the best way to resolve this conflict
While I believe it is possible to package kwin-x11 and plasma-workspace-x11 in a way that it does not depend on libraries from the main kwin and plasma-workspace at all, I am not convinced that this is the best way to resolve this conflict
Hmm, so at least @sgallagh's proposal with my amendment (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PWV5A6FJZOXIN3N4MXPQE75C6OR43AYX/), does not talk about lack of dependencies at all. The intent of the proposal is to say that even if some dependencies effectively exist, the KDE SIG may go forward with the update even if dependents haven't been updated quickly enough. The details of the implementation of the -x11 stack is left to its maintainers.
In case this is not clear from the mailing list thread:
That proposal is acceptable to me.
From my point of view it seems clear that the real problem is a longstanding friction between KDE-sig folks and folks who want to maintain plasma-x11.
Unless FESCo decides to drop X11 support for the whole distribution (meaning also Gnome and other DEs), my opinion is they should not block someone who wants to continue providing plasma-x11, since from all the discussions it is clear there are some users and use cases where it is still needed.
My feelings also are that the effort has high chances to fail, if both parties don't settle their grudge.
The discussion on fedora-devel has died down, or at least moved onto other topics.
So I'm making a formal proposal. This is @sgallagh's text with a small amendment:
KDE packages which reintroduce support for X11 are allowed in the main Fedora repositories, however they may not be included by default on any release-blocking deliverable (ISO, image, etc.). The KDE SIG should provide a notice before major changes, but is not responsible for ensuring that these packages adapt.
I'm +1 to @zbyszek 's proposal.
I'll also note that FESCo reserves the right to revisit this decision in the future if any involved party is failing to honor the spirit of the agreement. (For example, if the pro-X11 constituents try to force a hard dependency or the pro-Wayland constituents introduce impediments without sufficient technical justification.)
if the pro-X11 constituents try to force a hard dependency
A "hard dependency" as in Plasma Wayland having a Requires on Plasma X11? Why would we want to do that? We are not even going to impose a soft dependency (which we could using Supplements), and I am pretty sure even that would be frowned upon. And I do not see why we would want to do even that. The X11 subpackages have already been purely optional, not required or recommended, for several releases.
Supplements
if the pro-X11 constituents try to force a hard dependency A "hard dependency" as in Plasma Wayland having a Requires on Plasma X11? Why would we want to do that? We are not even going to impose a soft dependency (which we could using Supplements), and I am pretty sure even that would be frowned upon. And I do not see why we would want to do even that. The X11 subpackages have already been purely optional, not required or recommended, for several releases.
I'm not saying that you would. I'm just posing a hypothetical to make it clear that we intend to honor the spirit of this decision, not just the letter. I just came up with a contrived example for both sides to make sure no one confused my statement as being directed at one or the other.
The discussion on fedora-devel has died down, or at least moved onto other topics. So I'm making a formal proposal. This is @sgallagh's text with a small amendment: KDE packages which reintroduce support for X11 are allowed in the main Fedora repositories, however they may not be included by default on any release-blocking deliverable (ISO, image, etc.). The KDE SIG should provide a notice before major changes, but is not responsible for ensuring that these packages adapt.
s/major/breaking/
6.0.0 -> 6.0.1 is not major but would be breaking
I agree, "breaking changes" would be a clearer wording than "major changes".
I’m honestly confused about all of this. Wasn’t the whole idea of the F40 KDE 6 change to remove X11 functionality to nudge people to use Wayland? If we put the KDE 6 X11 modules back into the production repository without any other changes won’t this effectively upgrade all existing KDE 5 that have X11 installed to KDE 6 X11? Wasn’t the objective of the F40 KDE 6 change to prevent that from happening? I believe the language of the F40 proposal was quite explicit and was widely covered in the media. Why are we revisiting this? Why isn’t the COPR solution sufficient for those who absolutely must use X11? Unless I’m missing something, this move seems to effectively undo the approved change - at least for people who are doing upgrades instead of new installs, which is probably the vast majority of users.
Yup. Except Kevin already stated as such in the list: He's gonna make a copr that attempts to undermine our 'Obsoletes' of the x11-packages for users. For better or for worse.
Here's the quote, in case I get called a liar and attacked:
That said, since F39 is going to stick to Plasma 5 and F40 is going to ship only Plasma 6, something like Obsoletes: kwin-x11 < 5.90 in kwin-wayland might work. That said, I actually have a plan how to let users opt out of the Obsoletes before upgrading to F40, and that plan also depends on the Epoch: I want to create a Copr for F39 providing kwin-x11 5.x and plasma-workspace-x11 5.x packages with Epoch 1. Then the opt-in would be: 1. dnf copr enable kkofler/keep-plasma-x11-on-f40-upgrade 2. dnf upgrade 3. dnf copr disable kkofler/keep-plasma-x11-on-f40-upgrade 4. upgrade to F40 using any of the supported or unsupported methods (but DO NOT distro-sync F39 before upgrading – if you want to do that, do it in step 2 with the temporary Copr enabled).
I honestly was always under the impression that change proposals was, well, a change proposal to suggest going in one direction, and the approval as Fedora agreeing, as an entity, to go in said direction. I didn't know that a single user could simply override said direction. Feels like that weakens change proposals personally, but again, just my opinion.
I’m honestly confused about all of this. Wasn’t the whole idea of the F40 KDE 6 change to remove X11 functionality to nudge people to use Wayland?
The idea was not accepted by many members, especially by who use KDE daily and we think (at least I think) it is an absurd idea, forcing us to use wayland . So, IMHO, should be reverted , but as some people who took over KDE SIG, don't want revert it, we will provide an alternative .
It seems to me both kwin and plasma-workspace should expand their %description. It seems it is important enough package to have more information in them. Especially it should be clear non-x11 versions are supported by KDE-SIG, I would place that information into its %description. Seriously, could it contain at least two sentences from upstream README, explaining what it is for?
%description
For x11 versions, description should make it clear these versions are not maintained by KDE-SIG and I would recommend also mentioning legacy X11 support in its description, in any good variant. It should be clear they are supposed to be alternative versions. I haven't found that in their reviews.
As long as x11 variants can provide non-conflicting variants, I do not see a reason, why those packages should not be allowed. As long as they stay non-preferred version, which one needs to explicitly install or do dnf swap kwin kwin-x11, allow them to exist. If they get broken dependencies with x11 variants, it should be up to them to fix it. Of course kwin and plasma-workspace should allow them at least few days, before introducing breaking changes. Ideally using pull requests open for a week or so at minimum, before merging them and building ABI breaks.
dnf swap kwin kwin-x11
I do not use X11 for some time and it seems a bit backward to me, but I do not think anyone should be forced to use something they do not want. As long as they are willing to work for working alternatives and not break other's work, pretty please, let them. That is how I think community based distribution should work.
Yup. Except Kevin
ok
It seems to me both kwin and plasma-workspace should expand their %description. It seems it is important enough package to have more information in them. Especially it should be clear non-x11 versions are supported by KDE-SIG, I would place that information into its %description. Seriously, could it contain at least two sentences from upstream README, explaining what it is for? For x11 versions, description should make it clear these versions are not maintained by KDE-SIG and I would recommend also mentioning legacy X11 support in its description, in any good variant. It should be clear they are supposed to be alternative versions. I haven't found that in their reviews. As long as x11 variants can provide non-conflicting variants, I do not see a reason, why those packages should not be allowed. As long as they stay non-preferred version, which one needs to explicitly install or do dnf swap kwin kwin-x11, allow them to exist. If they get broken dependencies with x11 variants, it should be up to them to fix it. Of course kwin and plasma-workspace should allow them at least few days, before introducing breaking changes. Ideally using pull requests open for a week or so at minimum, before merging them and building ABI breaks. I do not use X11 for some time and it seems a bit backward to me, but I do not think anyone should be forced to use something they do not want. As long as they are willing to work for working alternatives and not break other's work, pretty please, let them. That is how I think community based distribution should work.
I have no issues with this, except for one specific one:
Of course kwin and plasma-workspace should allow them at least few days, before introducing breaking changes.
Many updates unfortunately will introduce breaking changes, as plasma (from experience) gets soname bumps very often. Right now, updating the whole kde stack (~400 packages if you add together frameworks, plasma and gear) takes 3-4 days at the very least as-is, do you suggest we add an additional couple days leeway wait-time before release? That factoring in real life availability and such could make kde updates potentially much longer.
I believe we spoke internally about this, and suggested simply filling a bug against the plasma-workspace-x11/kwin-x11 repos when we post a new version on distgit.
Yup. Except Kevin This is objectively a lie , many people , members of Fedora on devel mailing list, express that they want have X11 , in fact we have many people that defend keep X11 .
This is objectively a lie , many people , members of Fedora on devel mailing list, express that they want have X11 , in fact we have many people that defend keep X11 .
Wow you really selectively chose that quote, don't you.
I said the following:
Not that kevin is the only one what wants to keep x11. Please do not put words in my mouth.
Yup. Except Kevin This is objectively a lie , many people , members of Fedora on devel mailing list, express that they want have X11 , in fact we have many people that defend keep X11 . Wow you really selectively chose that quote, don't you. I said the following: Yup. Except Kevin already stated as such in the list: He's gonna make a copr that attempts to undermine our 'Obsoletes' of the x11-packages for users. For better or for worse. Not that kevin is the only one what wants to keep x11. Please do not put words in my mouth.
very sorry ,I'm trying remove my comment so they have to remove the obsoletes , they haven't the right of break path upgrade
Just one last reply to clarify something here. I'm not hostile to the idea of reintroducing x11, heck I wholly respect the spirit of the whole Linux experience, which is to allow it's users to use whatever they want however they want.
The only issue I'm seeing here is with the spirit of reintroducing the package. Again -- I'm not attacking Kevin or Sergio here, it is 100% within their rights to request those packages to be added. My worry is how it'll be interpreted by the general public and pretty much anyone outside of Fedora. Heck, some outside news sources are already starting to pick up on this, and are pretty much confirming my worries:
https://youtu.be/4QY6ADlspTQ?si=ZTf1i6Sl1WnxkgvB&t=299
@gbcox:
I’m honestly confused about all of this.
Well, a lot of the questions you ask were already answered in the discussion above and/or on the mailing list. But let me answer them again for you:
Wasn’t the whole idea of the F40 KDE 6 change to remove X11 functionality to nudge people to use Wayland?
"The whole idea of the F40 KDE 6 change" is to, well, upgrade Plasma to Plasma 6. (FYI, KDE stopped calling Plasma "KDE" somewhere in the Plasma 4 cycle.) Dropping X11 support from the packaging is an implementation detail.
If we put the KDE 6 X11 modules back into the production repository without any other changes won’t this effectively upgrade all existing KDE 5 that have X11 installed to KDE 6 X11?
No, it will not. DNF will prefer the Obsoletes in the -wayland packages to upgrading the existing -x11 packages (i.e., it will remove, not upgrade, the -x11 packages on the initial upgrade to Fedora 40, and once removed, they will only ever be brought back in if explicitly installed by the user). As already mentioned in this ticket, I have tested this, see: https://bugzilla.redhat.com/show_bug.cgi?id=2260793#c13
Obsoletes
(I will probably provide a way to explicitly opt out of that Obsoletes through a Copr, see the mailing list message quoted by @farchord, but by default, the Obsoletes will happen unchanged.)
Wasn’t the objective of the F40 KDE 6 change to prevent that from happening?
And nothing changes there, see above.
I believe the language of the F40 proposal was quite explicit and was widely covered in the media.
The somewhat misleading communication to media (implying that the X11 packages WILL be dropped, period) is not my fault though. I already pointed out in the Change discussion that the package may be reintroduced by others/me:
https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/5
and a KDE SIG member was quick to clarify that that was indeed allowed and that the Change only meant that the KDE SIG will not maintain those packages:
https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/11
(interestingly, the very same KDE SIG member who filed this ticket attempting to block that now), but the wording of the Change proposal itself was unfortunately not changed.
Why are we revisiting this?
I, for one, am not revisiting any past decision, only actually implementing the decision I had already announced back in September (see above).
Why isn’t the COPR solution sufficient for those who absolutely must use X11?
Because Copr is by definition unsupported and not an official part of Fedora. And also because that kde6-x11-unsupported Copr is maintained by people who do not actually want to maintain those packages and who are not making any long-term guarantees about them.
Unless I’m missing something, this move seems to effectively undo the approved change - at least for people who are doing upgrades instead of new installs, which is probably the vast majority of users.
You are missing something: This move does not change anything about the X11 packages getting obsoleted by the Wayland ones by default.
@farchord:
And I do not really see the issue there. That Copr, if implemented, is, like all Coprs, going to be purely opt-in. It will not change what will happen by default. I am not trying to disable your Obsoletes in Fedora proper.
I am just thinking of offering this alternative workflow:
instead of the official workflow:
because with that setup, the users will have no Plasma X11 between step 1 and 2, leading in the worst case (if Wayland is not working at all on the machine for some reason) to no working Plasma and having to do step 2 in text mode, or more realistically, having to do step 2 on Plasma Wayland.
Is it really such a big deal to offer the explicit opt out? In both workflows, there is an explicit opt out that the user has to perform to keep Plasma X11 installed.
Why would I call you a liar?
No, it effectively undoes a substantial part of the Change proposal. With the exception of the "Benefit to Fedora" section, every section includes information about eliminating the X11 session.
We already did the "switch" back in Fedora 34. Reintroducing the -x11 packages literally undoes the F40 transition and reverts us back to the F34 setup.
If you wanted some guarantees about the COPR, you could just ask for us to provide a timeline of maintenance. You've assumed that we'd torch it when I went through the effort of creating it and ensuring that if people use it that the packages wouldn't get replaced by the Fedora package that obsoletes the X11 session.
No, it reverts us to the F39 setup, where Wayland is the default, but X11 is available. F35 through F39 still ship Plasma X11 support even though it is not the default. So I do not see how it would revert us back to the F34 setup to keep shipping what F35 through F39 also shipped.
We already did the "switch" back in Fedora 34. Reintroducing the -x11 packages literally undoes the F40 transition and reverts us back to the F34 setup. No, it reverts us to the F39 setup, where Wayland is the default, but X11 is available. F35 through F39 still ship Plasma X11 support even though it is not the default. So I do not see how it would revert us back to the F34 setup to keep shipping what F35 through F39 also shipped.
The configuration in F39 was introduced in F34. Thus, it's the "F34 setup".
@pemensik:
That is actually not going to work. You want to dnf install plasma-workspace-x11 (which will also install kwin-x11) and then change to the "Plasma (X11)" session in SDDM. It will likely not be possible to remove kwin-wayland and plasma-workspace-wayland completely due to dependencies. And it will definitely not be possible to remove the main kwin package, which is shared.
dnf install plasma-workspace-x11
plasma-workspace-wayland
@ngompa:
If you wanted some guarantees about the COPR, you could just ask for us to provide a timeline of maintenance.
I asked you exactly that question in this very ticket, not once: https://pagure.io/fesco/issue/3165#comment-893794 but twice: https://pagure.io/fesco/issue/3165#comment-893912 and got no answer either time.
You've assumed that we'd torch it when I went through the effort of creating it and ensuring that if people use it that the packages wouldn't get replaced by the Fedora package that obsoletes the X11 session.
What else can I do than make assumptions if you do not bother answering when I ask?
@kkofler Thanks for your quick reply and I appreciate you taking the time to give another summary. However, the change proposal clearly states: “ This upgrade is also notable that for Fedora Linux (and Fedora Extra Packages for Enterprise Linux 10, once that materializes), KDE Plasma will not offer an X11 session.”.
I supppose we could get into a word parsing about this, but the clear meaning (at least to me) is that if something isn’t offered that means it isn’t in the production repository - that is why the media reported that X11 was going away for KDE 6 in Fedora. I don’t understand how we (Fedora) could twist things to have that sentence mean something else and that the rest of the world misunderstood it.
Of course FESCO can do what they want and reverse their decision or try to walk it back… but if they do, I fear that sends the wrong message about Wayland and it’s readyness. Effectively, doing more damage than good.
Regardless of the perceived inferiority of COPR, that seems to me to be the best compromise to resolve this situation.
@ngompa: If you wanted some guarantees about the COPR, you could just ask for us to provide a timeline of maintenance. I asked you exactly that question in this very ticket, not once: https://pagure.io/fesco/issue/3165#comment-893794 but twice: https://pagure.io/fesco/issue/3165#comment-893912 and got no answer either time. You've assumed that we'd torch it when I went through the effort of creating it and ensuring that if people use it that the packages wouldn't get replaced by the Fedora package that obsoletes the X11 session. What else can I do than make assumptions if you do not bother answering when I ask?
Sorry, I missed it because of the large wall of text.
At least from my perspective, I intend to keep the COPR active and maintained for at least 2-3 years. There were certainly some exceptional use-cases (VMware mainly) that people brought up that I am working through with the various products, projects, and upstreams to close on. The KDE SIG is willing to commit to shipping updates of kwin-x11 and plasma-workspace-x11 in COPR during at least that timeframe. We can certainly revisit that at a later date based on how many gaps are left to close.
@gbcox, IMHO, the proposal should never have been approved with this wording (and as mentioned, I had in fact pointed that out back in September), but that is hardly my fault, so I do not see how it would be fair to restrict my right to submit packages in Fedora (which any sponsored packager in Fedora has) because of it.
The intent was clearly to state that the KDE SIG will no longer support these packages (as the KDE SIG themselves had stated in September, even though they now attempt to backpedal on that statement), the proposal should not have asserted that they will be removed from Fedora completely.
@ngompa: Thank you for your answer.
So that is longer than I had feared, but still, if we go with your Copr-only approach, we are going to have the same debate 2-3 years from now.
My plan for the packages I submitted is to continue supporting them for at least as long as upstream supports X11, possibly longer if it can be forward-ported somehow.
@ngompa: Thank you for your answer. So that is longer than I had feared, but still, if we go with your Copr-only approach, we are going to have the same debate 2-3 years from now.
That is the point. X11 is still basically dead upstream and upstream efforts are primarily around Plasma Wayland.
@kkofler I’m not blaming you about the wording. I’m just pointing out that is the wording - and FESCO approved it. Once that happened, the cat was out of the bag so to speak. Now we are in a situation where I truly believe we will be sending the wrong message about Wayland if we revoke or walk back the decision.
I think user experience (users having a need for Plasma on X11) and packager freedom (being allowed to submit packages that follow all Fedora guidelines) ought to weigh higher than media reception due to what was ultimately a misunderstanding.
And besides, Wayland still not being ready for prime time does not sound that incorrect a message to me personally, but that is just my humble opinion.
(To be honest, I doubt Wayland ever will be ready for prime time.)
It was not a misunderstanding. Fedora KDE has been communicating about this for 4 years in various venues.
And besides, Wayland still not being ready for prime time does not sound that incorrect a message to me personally, but that is just my humble opinion. (To be honest, I doubt Wayland ever will be ready for prime time.)
It's going to have to be, since all the upstream X developers are working on Wayland now. Upstream KDE developers are primarily working on Plasma Wayland as well.
The misunderstanding was to believe that the Change process is an appropriate process for banning otherwise acceptable packages from entering Fedora, or that there should even be a process for such a thing to begin with. IMHO, that sets a very dangerous precedent.
You are free to stop maintaining the X11 subpackages, but other packagers should be free to pick up what you dropped. (See also the unorphaning and unretirement processes, though in this case there was no formal retirement because what you dropped were technically subpackages.)
We have been doing that as long as I can remember. Offhand, we've had at least one removal Change every release since F34:
The point of Changes is to have a distro-wide policy in place communicated in such a way that everyone knows what we're doing and what has been agreed upon.
The difference is that in all those cases, nobody was interested in bringing the deprecated package back.
This case is different. Here, we have both a lot of users asking for those packages and at least 3 maintainers (me, @stevenfalco who offered to comaintain, and @sergiomb who took the review requests) willing to bring them back.
@ngompa I think it is okay for any maintainer to orphan his package, especially if the X11 is dead. We all know it. But if those guys want to take burden to maintain those packages themselves, I somehow fail to see why it should not be allowed. Frankly, we have more packages, which still compile and are present, but have been obsoleted by something else.
It seems to be quite different thing to say something is discouraged and that something is banned from Fedora repositories. Despite it has no licensing problems.
Can you please name exactly which MUST checks it does not pass? I have failed to find deprecated() in xorg-x11-server.spec, accoding to Deprecating Packages. Am I doing something wrong? Is it deprecated properly and I just do not see it?
deprecated()
I somehow find not acceptable preventing others maintaining packages you do not want to. It is not okay to say nobody else can have the package in official repository. Have we done that ever before? Is there a good reason for that?
xorg-x11 is not dead upstream and it is maintained , also upstream didn't deprecated X11, just KDE SIG said that X11 is deprecated
the examples of wild changes mention , don't remember have any people that disagreed with it
xorg-x11 is not dead upstream and it is maintained
We have clearly very different understandings of what "maintained" means: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UH7PJA3SIYODHJ5ZYAHFO6KFQEGVAMWE/
You can also read a nice explanation by Nate: https://pointieststick.com/2023/09/17/so-lets-talk-about-this-wayland-thing/
also upstream didn't deprecated X11, just KDE SIG said that X11 is deprecated
We don't say it's deprecated. We accept that for all intends and purposes, Xorg implementation of X11 is unmaintained
@marcdeop Thanks for posting that link… which just further proves the point of what I’ve been saying. From the article: “ Fedora has always been a “leading edge” distro that pushes forward the technical state of the art on Linux by adopting new technology once it’s mostly ready, thus causing it rapidly improve in a way that it otherwise would not have. Fedora was the first distro to adopt Systemd, PulseAudio, and PipeWire. It was the first to use the Plasma Wayland session by default. And now Fedora KDE wants to be the first to drop the Plasma X11 session entirely and make everyone use the Plasma Wayland session.”
Seriously, what are we doing here? The decision has been made, if people want to use X11, there is COPR. I know this will make some people unhappy, but there have been times I have disagreed with FESCO decisions, but I have accepted, got behind the decision and moved on.
You can also read a nice explanation by Nate: https://pointieststick.com/2023/09/17/so-lets-talk-about-this-wayland-thing/ @marcdeop Thanks for posting that link… which just further proves the point of what I’ve been saying. From the article: “ Fedora has always been a “leading edge” distro that pushes forward the technical state of the art on Linux by adopting new technology once it’s mostly ready, thus causing it rapidly improve in a way that it otherwise would not have. Fedora was the first distro to adopt Systemd, PulseAudio, and PipeWire. It was the first to use the Plasma Wayland session by default. And now Fedora KDE wants to be the first to drop the Plasma X11 session entirely and make everyone use the Plasma Wayland session.” Seriously, what are we doing here? The decision has been made, if people want to use X11, there is COPR. I know this will make some people unhappy, but there have been times I have disagreed with FESCO decisions, but I have accepted, got behind the decision and moved on.
I've been thinking this exact same thing... This is really not what fedora does, maintain old technologies... I was under the impression that fedora pushes the envelope.
I think introducing new technologies and removing older, but still wanted by people willing to work on them, is a very different category. Driving packages outside official repositories, while meeting all packaging guidelines, would be a very dangerous precendent. I would not like it for RHEL, but could understand support for it is still paid by a single company. But we have here people willing to work on it from unrelated people. I still do not understand, why it is proposed to tell them they cannot.
Hi. Could I plead with everyone posting here to stop and instead go back to the devel list thread?
Posting here only reaches a small subset of interested people. This ticket should just be for fesco to vote or the like normally...
Hi. Could I plead with everyone posting here to stop and instead go back to the devel list thread? Posting here only reaches a small subset of interested people. This ticket should just be for fesco to vote or the like normally...
Sorry, the discussion in the list died down, and I dont remember who said that we'd go back in this thread lol I think that's why we all came back here
Metadata Update from @zbyszek: - Issue tagged with: meeting
At today's FESCo meeting, we agreed on the following proposal:
For additional clarification: this means that all users performing upgrades MUST be migrated to the Wayland session. They then MAY opt-in to the X11 session by installing a package for that purpose. We are explicitly not providing detailed technical implementation requirements here, but we expect all parties to follow the spirit of this decision when making technical decisions.
Metadata Update from @sgallagh: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Ref: https://pagure.io/Fedora-Council/tickets/issue/481
For the technical details that were brought up in the meeting, please see: https://bugzilla.redhat.com/show_bug.cgi?id=2260793#c33
Log in to comment on this ticket.