Take these human-readable files and normalize their content and

location:
   README                     Our blurp, tooting our horn
   INSTALL                    The run_all_autoconf and friends incantations
   COPYING                    GPL 2.0 license
   distcc/README              Martin's blurp
   distcc/INSTALL             Also: more on masquerading, host lists,
   distcc/COPYING             GPL 2.0 license
   distcc/NEWS                Recently updated
   distcc/AUTHORS             Martin Pool
   distcc/README.packaging    Various advice (version numbering etc)
   distcc/TODO                A very long list (not updated)
   distcc/ChangeLog	      All changes under arch and under bzr
   distcc/ChangeLog.old	      All changes from before arch.

Now all live in the top-level directory.  This is the first step
towards our eventual goal of getting rid of the second-level distcc
and include_server directories, and just having everything under one
top-level directory.  We're all part of the same project now!

Here's how I merged and updated content:

. README became README.pump.  It was slightly edited for clarity.  (I
  also redid all the line-wrapping, which makes diff-ing
  difficult. :-( )  distcc/README became README, with a small amount
  of text added to describe 'pump' mode, and point to README.pump.

. distcc/NEWS became NEWS.  pump functionality was added (a new
  "distcc-3.0" entry).  I also added all new features and bug-fixes
  since we moved from arch to bzr.  It looks like NEWS was
  well-maintained before the move to bzr, so this might be pretty
  complete.  There may be some more pump-developed bugfixes we need to
  add, though.

. I got rid of distcc/COPYING.  Now COPYING is the only license in
  this directory.  This file was not changed.  It remains the GPL 2.0
  license.

. distcc/AUTHORS became AUTHORS.  I changed Martin to maintainer
  emeritus.  I added the Google authors as authors of the "pump"
  functionality, and current maintainers.  I set the Google email
  address to be distcc@googlegroups.com, which is a new group I've set
  up to be the clearinghouse for distcc discussions.

. distcc/README.packaging became README.packaging.  It was not
  otherwise changed.

. distcc/TODO became TODO.  It was not otherwise changed, except I
  added that folks should look for FIXMEs in source files, not just
  TODOs.

. I merged INSTALL and distcc/INSTALL (in that order).  I rearranged
  the text a little bit to remove redundancy (both talked about
  running 'configure'), but did not make any contentful changes.

. I merged distcc/ChangeLog and distcc/ChangeLog.old to have a single
  changelog again going all the way to 2002.  Comments now separate
  the various version control systems used.  (svn is #4!)  The single
  ChangeLog file now lives in the top-level directory.

1 files changed, 75 insertions, 0 deletions

diff --git a/README.packaging b/README.packaging
new file mode 100644
index 0000000..1b35ccd
--- /dev/null
+++ b/README.packaging
@@ -0,0 +1,75 @@
+$Id: README.packaging,v 1.7 2004/02/20 04:11:26 mbp Exp $  -*- indented-text -*-
+
+Please read this file if you distribute packages of distcc and
+consider these requests.
+
+ - If you make available packages or ports for some system, please
+   send mail to the list so that I can include a link on the web site.
+
+ - If you make change to program, please append to the version number
+   so that it can be distinguished from the upstream version, e.g. in
+   bug reports, and document your changes.  (For example, change it to
+   "0.13-foo11" if you modify it for the Fooix distribution.)
+
+   I request this because I have had distributors introduce broken
+   patches into distcc, and if somebody asks for support I want to
+   know they're not using the same source.  I have seen this happen on
+   samba and rsync as well and it wastes everybody's time when the two
+   parties see different programs as "foo-1.2.3".
+
+   In the steady state there ought to be little need for distributors
+   to patch anything; any reasonably portability fixes will be merged
+   and if they add new features it deserves a different version.
+
+ - Please install distccd into a directory that is on the default
+   $PATH.  (If sbin is not on the path for all users, please don't put
+   it there.)  This is important to making ssh work without hassle,
+   and is compliant with the Linux filesystem hierarchy standard
+   (FHS).
+
+ - distcc uses the standard GNU configure options to set installation
+   directories.  In particular, you may want to change --prefix=/usr,
+   and --sysconfdir=/etc.  In addition you can use $(DESTDIR) when
+   doing "make install" to install into a virtual root directory.
+
+ - Because the daemon does not authenticate connections, please check
+   that the administrator understands the consequences before starting
+   it.  Do not start it automatically when the package is installed.
+
+ - If your installation script prompts for parameters, consider asking
+   for a list of allowed netmasks to pass to the daemon's --allow
+   option.
+
+ - When installing the daemon, please create a system user called
+   "distcc" for the use of the daemon.  This is better than running
+   the daemon as "nobody".  You can either remove the user or leave it
+   around if the package is uninstalled, depending on your
+   distribution's policy.
+
+ - I'd prefer for distributions to arrange for distccd to run as a
+   standalone daemon (--daemon), not from inetd.  It is a bit easier
+   to support, and in the future there may be optimizations that only
+   work in standalone mode.
+
+ - If any patches are necessary for portability please forward them to
+   me so that they can be considered for inclusion upstream.
+
+ - Check that distcc uses shared libraries for popt and other things,
+   if that makes sense on your system.  In particular, make sure
+   libraries in /usr/local are linked properly.
+
+ - Try to make sure gcc is installed with fully-qualified names to aid
+   users of distcc.  (e.g. 'gcc-3.2', 'i386-linux-gcc-3.2' and
+   'i386-redhat-linux-cc-3.2.2').  This makes it much more likely that
+   people will be able to plug-and-go for cross-architecture or
+   cross-OS builds.  It's good to name even native compilers this way
+   so that they can participate in heterogenous builds.  If you don't
+   maintain the compiler packages for your OS, please talk to the
+   person who does.
+
+ - Consider putting this line into /etc/services
+
+distcc		3632/tcp			# distributed compiler
+
+
+Thankyou for your help.