On Sun, Jan 29, 2012 at 05:44:46PM +0100, Ralf Mardorf wrote: > On Sun, 2012-01-29 at 16:57 +0100, Martti Kühne wrote: > > it's actually possible to get most features that come with gdm, eg. > > session chooser, working with xdm. > > This was the same for GDM. What would you do if the next upgrade will > make XDM depend to PA? Of cause, you'll simply install another login > manager. But what will you do if really important applications get such > an unneeded dependency and it will break your work flow completely? Umm, I'd focus efforts and patch it already out there. Or maybe I'd write my own display manager. XDM is, as the name implies, intended as a sane default, if you don't like it you're invited to replace it with something more fitting for your purposes. Actually a recurring trend in the linux world is the origin of software right out of this kind of flamewar-fermented discussions, and new solutions pop up where software that has reached a certain age gets feature bloated and unfitting for your particular purpose. So, you're the guy to change that and write a new display manager for X? I'd happily help you. However this is a downstream mailing list that does not benefit of this discussion, because the only thing I've been reading for two days now is that there are ppl pissed with dumb upstream decisions... and it's still not an arch problem. You cannot expect us, as users of this distro to solve the issues you create yourself through unflexible decision making and this non-coder's attitude. You want to focus on more important things, then do that already. I really expected you'd guess that some time. > That's the point. Again and again and again, it's no problem as long as > it is for PA only and you've the knowledge to build a dummy package. Great. So the patches for the actual problem - GDM - are out next week? Leave a message if you need any help with that. You would naturally start with $ cd ~/abs; cp /var/abs/extra/gdm .; cd gdm; makepkg -o; cd src/*/ > Fortunately some packaging things for Arch are completely different to > some old major distros. So, in this case it seems to be an issue cause > upstream, but the more people understand what's the problem is, the > better WE can inform upstream. Yup. I did have trouble with opencbm, and sorting it out I used sed, source diving and reading about make/workingset magic for a few hours. Oh I do read stuff and have no idea about Xlib, and I still manage to set up a more or less crappy desktop environment based on st, dwm, and sandy - incidentally all low-sloc suckless apps which are small enough so I am actually able to debug my self-induced problems. Can't tell how much time I spent on reading xlib manuals to get to a solution more by accident... don't care, either, because it's fun. > When I've got a set up and I'll upgrade it, it's ok if things get > borked, because of a new sound server. But if a group of people file bug > reports, than it's ignorant not to fix the new sound server, but instead > to demand that it must become dependency for more and more software even > if it has nothing to do with audio. yeah, if you'do not have a linus (in the software sense) and rms (in an ideologic sense) sitting on some dictatorship form of running things around here (is it godwin time yet?), all the other wannabes would fork linux to death. I do support the freedom of choice, but I do not feel obliged to patch gdm for you, because it's just not currently my problem. cheers! mar77i
