The following ebuild is an updated version wich allow installation of wesnoth as a server on a headless system (without X). It also update the package to 1.0_rc1, because newer version of the client aren't compatible with olders version of the server. And add a rc.d daemon. I needed this and so distribute it. Hope it can help.
Created attachment 69880 [details] wesnoth-1.0_rc1.ebuild
Created attachment 69881 [details] wesnothd.rc The rc script
Comment on attachment 69880 [details] wesnoth-1.0_rc1.ebuild The ebuild
well, 1.0 is out and in portage so this won't go in as presented. However, the concept is good. Care to update it to the 1.0 ebuild? Instead of the X use flag, the dedicated use flag should be used.
Created attachment 69886 [details] Updated version, thanks to Mr. Bones I now use the "keepdir" directive, put enewuser in both pkg_setup and pkg_preinst sections, and removed enewgroup. So it is much better now ! Thanks a lot !
Why are we adding a new user for this? None of the other dedicated servers do that afaik. That's why we have GAMES_USER_DED. Also, use newinitd for the init.d install please.
Created attachment 69888 [details] wesnoth-1.0.ebuild (In reply to comment #6) > Why are we adding a new user for this? None of the other dedicated servers do > that afaik. That's why we have GAMES_USER_DED. I hadn't read the game eclass. I know I should have. It use GAMES_USER_DED and GAMES_GROUP now. > Also, use newinitd for the init.d install please. Done.
Created attachment 69889 [details] wesnothd.rc This version of the rc script run wesnothd as ${GAMES_USER_DED:-games}:${GAMES_GROUP:-games}
GAMES_USER_DED and GAMES_GROUP are build time options, not runtime
Created attachment 69896 [details] wesnoth-1.0.ebuild It now use sed to inject GAMES_USER_DED and GAMES_GROUP in the rc script.
Created attachment 69897 [details] wesnothd.rc The corresponding rc file. Hope I'm rigth this time.
looks good to me ... ive never used wesnoth, but does the server daemonize itself and allow for all these options ? or is using ssd the only option ?
(In reply to comment #12) > looks good to me ... ^_^ If it his not, i'll do what is necessary > ive never used wesnoth, but does the server daemonize itself and allow for all > these options ? or is using ssd the only option ? wesnothd can demonize itself, but then don't keep track of PID (at least the doc say nothing about it) Furthermore, it doesn't allow to run itself as another user (could do it with suid but i think it would be worst) The manpage is available here : http://savannah.gnu.org/cgi-bin/viewcvs/wesnoth/wesnoth/doc/man/wesnothd.6?rev=HEAD&content-type=text/vnd.viewcvs-markup
then the best option we have atm is ssd ... unless someone feels up to adding these features to wesnoth itself and sending the patches upstream :)
The requested versions are in portage for a long time now. This bug can be CLOSED! BTW there is a new "unstable" release 1.1 upstream.
Newer ebuilds in portage include this feature. Thanks !
