On Thu, Apr 24, 2025 at 6:36 PM Michel Lind <sali...@fedoraproject.org> wrote: > > On Thu, 2025-04-24 at 18:13 -0400, Neal Gompa wrote: > > On Thu, Apr 24, 2025 at 6:11 PM Michel Lind > > <sali...@fedoraproject.org> wrote: > > > > > > On Thu, 2025-04-24 at 17:53 +0000, Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > On Tue, Apr 22, 2025 at 07:55:53PM +0100, Aoife Moloney via > > > > devel- > > > > announce wrote: > > > > > == Benefit to Fedora == > > > > > This aligns us with the effort going on upstream to retire the > > > > > GNOME > > > > > X11 session. It also aligns us with Fedora KDE. Like the Fedora > > > > > KDE > > > > > SIG, the Fedora Workstation WG recommends and supports the > > > > > Wayland > > > > > platform for graphics. > > > > > > > > > > Fedora Workstation has a long history of developing and > > > > > promoting > > > > > the > > > > > Wayland experience for GNOME, and > > > > > [ > > > > > https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA > > > > > it > > > > > has been the primary experience for all users (including those > > > > > with > > > > > NVIDIA cards) since Fedora Linux 36]. This continuation of > > > > > [[WaylandOnlyGNOMEWorkstationMedia|the work in Fedora Linux 41 > > > > > to > > > > > drop > > > > > the X11 session from the media]] reaffirms our commitment to > > > > > the > > > > > Wayland GNOME experience in furtherance of the goal to provide > > > > > the > > > > > highest quality GNOME experience through Fedora Workstation. > > > > > > > > I find this motivation a bit of a stretch. > > > > > > > > Firstly, it doesn't really align us with upstream, since we're > > > > doing > > > > something that upstream is not doing (yet). > > > > > > > > Secondly, I see little benefit in "aligning" the Workstation > > > > Edition > > > > with KDE. We have both because they are different. > > > > > > > > Thirdly, I'm very happy that the WG recommends Wayland and that > > > > there's a long history of championing Wayland by Fedora. But this > > > > doesn't mean that we should drop support for an alternative. > > > > > > > > The benefits of dropping code are different for upstreams and for > > > > downstreams. For the upstream, dropping an feature like this can > > > > result in removing a lot of code, and then possibly they can get > > > > rid > > > > of some abstraction layers or limitations, also compile times > > > > improve, > > > > testing is simplified, etc. But for downstreams that aren't > > > > developing > > > > the code, those benefits are much smaller. The compile times > > > > improve > > > > a > > > > bit, possibly there are less subpackages, but that is just some > > > > CPU > > > > time. The only big change is that the support matrix is smaller. > > > > > > > > In the case of the X11 sessions, one has to explicitly select > > > > the session. This is something that users who explicitly want it > > > > will do. And if they do this, this is most likely because > > > > $something > > > > doesn't work well under Wayland for them. Maybe it's the fault > > > > of their custom config or hardware, that doesn't really matter. > > > > But since this is clearly opt-in, whether the feature is there or > > > > not does not make that much of a difference for maintainers. > > > > > > > > I don't personally care for the X11 and I haven't used it in > > > > years. > > > > But I think that those X11 subpackages and the users who use them > > > > are > > > > not a problem and there is little benefit in accelerating the > > > > removal > > > > of X11 before upstream. > > > > > > > Marking these as deprecated() could be a reasonable compromise - > > > after > > > all, upstream is already disabling it by default for 49 and will be > > > removing it in 50, right? > > > > > > So marking these as deprecated seems reasonable - these will have > > > to > > > eventually go away anyway, and this signals to users to not rely on > > > these packages for much longer and for packagers that they should > > > not > > > package something that hard-depends on these. > > > > > > > They were marked as deprecated since Fedora Linux 40 already. > > > For gdm there is no subpackage right now though, right? > > e.g. this is the commit restoring X11 support in F42 > https://src.fedoraproject.org/rpms/gdm/c/21ea3e2aaba10f49a08c13f317da6c48ab2b546e?branch=f42 > > So a next step forward could be to ship those files in a deprecated > gdm-x11 subpackage - whether that's installed by default or not is a > separate question. Likewise with other packages that might be packaged > similarly at the moment. >
Unfortunately, we can't because that just results in a broken GDM. GDM will happily give you a black screen if the stuff isn't installed and GDM is build-time configured to allow X11 sessions. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
