Why are we packaging?

[James Cameron <quozl@us.netrek.org>]

Bob, if I revisit my vision for why we are doing this, perhaps this will
fill in some of the gaps and help you to see why the answers might be
fairly clear.  Not that I don't mind answering questions, but I would
rather we are in agreement on the central goal and the initial thrust to
get to that goal.

My primary purpose in packaging for the Linux market is to increase the
playerbase.  I believe that two full servers operating simultaneously is
insufficient.  One of the best sources of new players, I think, will be
people who are trying out Linux.  They install a distribution and wander
through the games.  I want them to find Netrek on a distribution CD.

Now, to get onto a distribution CD takes a lot of effort.  The packaging
has to be done, and the product has to look good.  This is why I've
started on the server administration GUI.  We can't choose to be
distributed, we can only make the product so desireable that it is
selected by the distribution creators.

We can get a secondary push into the existing Linux user base from the
announcement via http://www.freshmeat.net/, but we will get ignored
badly if the first push into that market fails due to something we have
done with the packaging that offends some people.

So, to address the current discussions ...

- newstartd -> netrekd ... needs to be done, and I have probably chosen
a wrong way to go about it.  I figured it was easy just to add a
symbolic link from netrekd to newstartd in the LIBDIR.  Although that
works, it needs to be in the PATH of the shell that starts it unless I
can figure out a way to change the output of ps.  Exactly how we
implement this is probably irrelevant, so long as;

	*  /etc/rc.d/init.d/netrekd is present and works properly,
	*  ps shows netrekd as the process name.

- why not inetd? ... we already have replaced inetd in order to provide
for better denial of service detection, speed of operation, ability to
simply delete a process to stop the acceptance of connections, and, in
the .tar.gz market, so that we don't need to run as root.  So although
inetd is the way some packages do it on Red Hat and Debian, I would
prefer to implement this in the same way that lpd is implemented; it
listens on startup and does not involve inetd.

- newstartd called from inetd? ... can't be done, as newstartd listens
on multiple ports.  You _can_ start ntserv from inetd, but then you
don't get the logging you get with netrekd.

- starting server before initial key load ... we should distribute a
baseline set of keys with the server kit.  We should not require the
user to be connected to the net at the time they start their at-home
practice server to try the game out with.  I want them to just type "rpm
-i Vanilla*" and off it will go.  Remember that since we also intend to
package a client at the same time, that client's keys must be in what we
distribute.

- logging ... as I said earlier, is a difficult one.  Our naming
currently matches the .tar.gz packaging.  Logging to /var/log/netrek/*
is more sensible for a distribution specific packaging.  We should
probably do better to fix this by adjusting the .tar.gz packaging to log
to ${prefix}/var/log/, and make a "proper" tree with bin, and lib,
within our current "LIBDIR".  Crossfire did this recently.

Questions:

- how do you change what "ps" sees about your process?

- can anybody else who uses any of the Linux distributions suggest any
other credibility increasing changes we can make?

-- 
James Cameron                                      (quozl@us.netrek.org)

Linux, Firewalls, OpenVMS, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.

"Specialisation is for insects." -- Robert Heinlein.