This may sound like an odd request, but it would be useful if /etc/init.d/xdm belonged to x11-apps/xdm rather than x11-base/xorg-server. I have a machine on which I run many X applications (including a full KDE desktop). I run xdm on this machine too, but I do not run Xorg and don't want x11-base/xorg-server installed (it conflicts with something unrelated I use on the machine). To connect to the machine I run an X server on another machine and use XDMCP to get a session. This is a completely valid way of using X windows. This works perfectly as long as xdm is running, but I have to create my own xdm script in /etc/init.d/xdm as the real one belongs to x11-base/xorg-server (as far as I can tell) and certainly isn't installed with x11-apps/xdm. Given that x11-apps/xdm is the package giving the xdm tool for which /etc/init.d/xdm exists, surely /etc/init.d/xdm belongs with x11-apps/xdm? I know there's kdm and various others, which might be the reason behind the odd ownership of /etc/init.d/xdm, but if that's the reason for /etc/init.d/xdm to not belong to x11-apps/xdm then surely it belongs in it's own package which is then a depencdency of xdm, kdm and any others (but not necessarily x11-base/xorg-server, which could be run without xdm anyway).
Note that you should be able to build x11-base/xorg-server with USE="-xorg -dmx -kdrive" to install none of the server implementations provided by the package.
A better place might be x11-apps/xinit
Or we should finally let each DM supply their own initscript. We don't have a 'cron' script multiplexing our cron daemons, we don't have 'syslog' multiplexing syslogs...
The code needed to start the individual DMs is not so much different between xdm, kdm, gdm etc. Maintaining it in one central place is maybe better. A possibility would be to make xdm/kdm/gdm etc. ship wrapper scripts that set some variables and then call a generic DM starter.
(In reply to comment #3) > Or we should finally let each DM supply their own initscript. We don't have a > 'cron' script multiplexing our cron daemons, we don't have 'syslog' > multiplexing syslogs... The idea was that there's no (valuable) use case for wanting to run multiple DMs at the same time. Hence having only one badly-named xdm script. It used to be in xinit a while back and it was moved from there since few DMs and DEs actually use/require xinit tools. Last time we discussed the whole thing, we decided that having the xdm init script installed by xorg-server was the lesser of many Evils™. This can be changed of course, but is it really worth the hassle for all our users and for our documentation? Cheers
(In reply to comment #5) > (In reply to comment #3) > > Or we should finally let each DM supply their own initscript. We don't have a > > 'cron' script multiplexing our cron daemons, we don't have 'syslog' > > multiplexing syslogs... > > The idea was that there's no (valuable) use case for wanting to run multiple > DMs at the same time. Hence having only one badly-named xdm script. > > It used to be in xinit a while back and it was moved from there since few DMs > and DEs actually use/require xinit tools. > > Last time we discussed the whole thing, we decided that having the xdm init > script installed by xorg-server was the lesser of many Evils™. > > This can be changed of course, but is it really worth the hassle for all our > users and for our documentation? Yes, if it means anything to not have dependencies that don't really make sense. At the moment some change to the documentation would be required to explain what to do if you want a server that can run desktops and X applications without having to have xorg-server installed on the machine with no monitor that nobody actually sits at. As the examples in comment #3 suggest, the precedent is already there for other services, but if one init file common to all is really a better solution than each DM having its own then the common init file could have its own package and be a dependency of all DMs. Another advantage of that is it would be easier for a DM to fork from that configuration if it became necessary.
not really a duplicate but fixed now anyways. see also github PR *** This bug has been marked as a duplicate of bug 730644 ***
