Both depend on xmodmap, due to /etc/X11/xinit/xinitrc /etc/X11/Sessions/Xsession /etc/X11/xdm/Xsession I'd like to add that I consider the xinit ebuild's minimal use flag as a bit problematic, since the mentioned scripts do call the binaries xrdb, xmodmap, twm, xclock and xterm regardless, if they exist or not, nor do they throw warnings.
(In reply to comment #0) > I'd like to add that I consider the xinit ebuild's minimal use flag as a bit > problematic, since the mentioned scripts do call the binaries xrdb, xmodmap, > twm, xclock and xterm regardless, if they exist or not, nor do they throw > warnings. The flag was added because users complained about useless junk (such as twm) they'll never ever use being a hard-dependency in the ebuild. Dunno how you, but I immediately hit Ctrl+Alt+Backspace if I happen to get trapped in the 'fallback' twm 'environment' with that fugly clock by some big mistake.
I'm aware of it Jakub, I don't use the "junk" either. It's still neither fine to call binaries, which do not exist, nor not to spit out proper error messages. Imho such ambiguous use flags like "minimal" shouldn't exist at all and in this case the scripts be fixed and these optional runtime dependencies removed from the xinit ebuild entirely. btw. I'm not familiar with upstream's activity. I wouldn't mind to improve the scripts, if there is a good chance it would be accepted and Gentoo's X11 team would be so nice and forward.
I'm very interested in both moving our scripts closer to upstream and adding useful features to upstream. It just takes someone to do the actual work -- sounds like that might be you. The minimal programs are only run as fallbacks, and I think that bit comes from upstream so I'd rather not change it. The xmodmap change sounds reasonable, so I'm adding the Inclusion keyword for that.
You lost me a bit Donnie. I didn't really look into X stuff, ever. So our scripts are completely custom ones and I have to patch against ones in the tarballs or better upstream? As said, I'd rather like to avoid getting in contact with yet another repository, just to fix three files.
(In reply to comment #4) > You lost me a bit Donnie. I didn't really look into X stuff, ever. So our > scripts are completely custom ones and I have to patch against ones in the > tarballs or better upstream? Not complete custom (at least not most of them), but they're a ways out. > As said, I'd rather like to avoid getting in > contact with yet another repository, just to fix three files. I can commit any patches to xorg for you, if you're willing to do the work.
Ok, so we've started working on xinit again, as we now finally have some time to work on such packages again. Now the idea is to apply proper and documented git-formatted patches to the upstream code instead of replacing files such as xinitrc with our own (what we used to do). With the current git master code, if USE=minimal is set, we could always define the utilities to /bin/true or something. That shouldn't require any patches AFAICS. If anyone wants to tackle this, the xinit-9999 ebuild is in the x11 overlay and has no dependencies on other overlay ebuilds : http://git.overlays.gentoo.org/gitweb/?p=proj/x11.git;a=tree;f=x11-apps/xinit;hb=HEAD If not, I'll get to it someday but any help is more than welcome. :) Thanks
Now that I've worked on xinit some more, this is a non issue IMO. The system xinitrc is just a default script. If you want to launch something else, just create your own .xinitrc in $HOME and the system one will be ignored. That's how I see xinit anyway. Thanks