Void-packages: sddm requires `xorg-server` as a dependency

Created on 12 May 2020  路  24Comments  路  Source: void-linux/void-packages

In testing sddm in a VM for the purposes of https://github.com/void-linux/void-docs/pull/237, i found that xorg-server is a dependency not specified by the sddm package.

All 24 comments

@Johnnynator

All DM-s require an X server somewhere,
it's not necessary the X server in the same machine.

So we should just mention it in the documentation?

I don't believe that desktop environments, or login managers, should require xorg... they could run under wayland, or the X server could be on a different machine, etc etc.

On 2020-05-12 17:48:37-0700, fosslinux notifications@github.com wrote:

I don't believe that desktop environments, or login managers, should
require xorg... they could run under wayland, or the X server could
be on a different machine, etc etc.

That's my point, too.

--
Danh

Oh, whoops, I just saw this issue and commented, I scrolled over your message. Sorry!

Well, i've been spending hours in VMs trying to work out what packages users need when trying to use DEs, for the purposes of the documentation i'm writing for the Handbook. Regardless of whether SDDM should have a hard dependency on xorg-server, my testing showed that it currently does - without xorg-server installed, SDDM simply doesn't work. Once SDDM is started, one can certainly choose a Wayland-based Plasma session, but that involves getting SDDM started in the first place. It's true that a particular setup might involve an X server running on another machine, but i doubt that's the most common use case for KDE users.

i'm opposed to 'fixing' this sort of issue via documentation. If something is a soft dependency, sure, let's note that in documentation. But for hard dependencies like this, i feel that either the sddm package should be modified to depend on xorg-server, that it be modified to work without xorg-server being installed, or that work is done by upstream so that xorg-server is no longer required.

On 2020-05-12 20:26:23-0700, Alexis notifications@github.com wrote:

i'm opposed to 'fixing' this sort of issue via documentation. If
something is a soft dependency, sure, let's note that in
documentation. But for hard dependencies like this, i feel that
either the sddm package should be modified to depend on
xorg-server, or that work is done by upstream so that this
dependency is no longer required.

Users would want to install either xorg or xorg-minimal, though.

--
Danh

As @sgn said, however, what if they did something like export DISPLAY=10.0.0.1:1 to do xorg over the network and launch sddm there? This is a valid usecase that would mean the user doesn't require an X server. I run sddm and it seems it wants a X socket/DISPLAY to access, not a hard dependency on xorg... Happy to be corrected though.

@fosslinux: It's certainly a valid use-case, but i doubt it's at all the most common one, which is what i'm trying to address here. Having xorg-minimal as a hard dependency wouldn't impact one's ability to set things up for the use-case you described, and it would give a better out-of-the-box experience for (what i believe to be) the majority of SDDM users.

I think this should be standardized across all DM, WM and DEs. What makes SDDM special that it should have this dependency? Why not add this requirement to (say) xfce4, etc?

Having xorg-minimal as a hard dependency is likely to pull in a lot of dependencies users may not necessarily want, and I think there should be a way to make it an optional dependency; ie, make it removable from the system, for usecases where sddm is needed but not an X server. Does XBPS have this ability?

My personal opinion for the best solution here would be to make a sddm-full package, or rename sddm to sddm-base, or something like that, introducing new package/changing the existing sddm package to depend on sddm/ sddm-base, xorg-minimal and potentially other goodies.

@fosslinux: i can't speak about other DMs, but gdm doesn't need it because it uses Wayland by default. (i haven't yet got to testing the minimal requirements for other DMs for documentation purposes.)

Installing xorg-minimal requires ~10M worth of downloads, and ~40M worth of disk space. Its current deps are just:

xorg-server>=0
xauth>=0
xinit>=0
xf86-input-libinput>=0

Other members of the Void team will have to comment on your packaging idea; it seems reasonable to me, but there might be issues i'm not aware of.

FWIW, xorg-minimal isn't a plug-and-play, then, for most devices, as most of the time you will need a xf86-video-{something} as well.

Again, in my testing, all that was needed to get the sddm package to work was xorg-server; i didn't need to install xf86-video-{whatever}.

(i'd also prefer that the eventual package structure be sddm with a dependency on xorg-minimal, and sddm-minimal for people who don't want that dependency. Again, i'm trying to address what i believe will be the most common use-case.)

Oh, that's right, I forgot modset was merged into xorg-server. My bad.

That packaging structure sounds reasonable to me.

I think a Void user is aware that when he wants to run a DE under X11 he has to install xorg (or xorg-minimal and some more). I don't think we want sddm to depend on packages which it really does __not__ depend on.

If anything you could perhaps create a sddm-easy or sddm-x11 PR as a meta package and put any dependencies you think are required for a good user experience into that one. I don't know if @void-linux/pkg-committers would accept that, though.

@pullmoll: The difficulty is when people intend to use Wayland for their Plasma sessions. People won't need to install X for that, but if they at least want to use SDDM, it doesn't work at all without xorg-server / xorg-minimal.

I admit I have no experience with Wayland. Still, the description of sddm reads "QML based X11 display manager" which should be sufficient to tell people they need X11 installed in case they want to run local sessions with sddm.

And if they don't want to install (also) the X11 dependency they should use a different DM, provided there is one which does not need X11 :)

Since the sddm maintainer is @the-maldridge I'd say we leave it to him to decide how to deal with this issue.

provided there is one which does not need X11 :)

Yeah, not sure if there is one or not. Certainly gdm pulls in xorg-server.

Since the sddm maintainer is @the-maldridge I'd say we leave it to him to decide how to deal with this issue.

*nod* And if he decides not to change sddm's dependencies, documentation it is: i'll update https://github.com/void-linux/void-docs/pull/237 accordingly.

I'm late to the party but I wouldn't want sddm (or other LM) to depend on xorg-server because of reasons already mentioned.

As a side note, if the decision is that DMs shouldn't have xorg-server as a (direct or indirect) dependency, then the gdm package will need to be modified to reflect that, since as i wrote above, it currently pulls in xorg-server.

(Ping @mnabid and @not-chicken, who are currently working on packaging GNOME 3.36.)

As a side note, if the decision is that DMs shouldn't have xorg-server as a (direct or indirect) dependency, then the gdm package will need to be modified to reflect that, since as i wrote above, it currently pulls in xorg-server.

(Ping @mnabid and @not-chicken, who are currently working on packaging GNOME 3.36.)

Gentoo's gdm ebuild has this: https://bugs.gentoo.org/295686 marked as reason for having xorg-server as a rundep. I wasn't able to reproduce it now though( would be better if someone else can test too) as it probably got fixed upstream sometime during the decade. If it's confirmed fixed, we can remove xorg-server safely.

The most correct action would be to have a virtual package for X, but that relies on components of xbps that are less stable than I'd like. The best and most straightforward action is to not patch this package, as adding the dependency would be inappropriate, and to not patch it out of gdm, as that could inadvertently break existing users.

Once virtual packages become a better option, having them depend on a virtual package for xorg with xorg-server being the default provides would be an acceptable option.

@the-maldridge: Thanks!

Was this page helpful?
0 / 5 - 0 ratings