docs: change README to describe procps-ng project

Reference: http://www.freelists.org/post/procps/PATCH-Clean-README
CC: Gilles Espinasse <g.esp@free.fr>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
This commit is contained in:
Sami Kerola 2012-02-24 22:08:12 +01:00 committed by Craig Small
parent 99c99baebc
commit 9639a1c901

78
README
View File

@ -1,70 +1,44 @@
COMPATIBILITY COMPATIBILITY
This code is intended for use with Linux 2.2.xx, 2.4.xx, This code is intended for use with Linux 2.6.xx, 3.x and
2.6.xx, and hopefully all future kernels. You should be hopefully all future kernels.
running a system with libc 6, but libc 5 might work too.
INSTALLATION INSTALLATION
If you are using git version of the project you need extra step.
./autogen.sh
After that, and everyone using .tar.xz version of procps-ng, can
do normal build. Read './configure --help' to select options for
your needs.
./configure
make make
make install make install
Only the second ("make install") is needed if you just If you have DejaGNU installed you can run optional test suite.
want to build and install procps-ng in the normal way.
If you wish to test before installing, use the scripts make check
named t, v, and p to ensure that the correct libproc
(the new one) is used during your testing.
You may set SKIP to avoid building or installing things.
For example:
make SKIP='/bin/kill /usr/share/man/man1/kill.1' install
Use SHARED=0 to build procps-ng without shared libraries.
This may be useful for installing in your home directory.
make SHARED=0 DESTDIR=$HOME install
Suppose you wanted to install stuff in strange places.
You might do something like this:
make usr/bin=/tmp/Q/i/ DESTDIR=/tmp/Q install="install -D" ldconfig=echo install
If cross-compiling, you might need to set lib64 to
either "lib" or "lib64". You might need to set m64 to
-m64, -m32, or nothing at all. Some examples:
make lib64=lib m64=-m32 # for a bi-arch gcc
make lib64=lib64 CC=x86_64-gcc
make lib64=lib CC=alpha-gcc
PACKAGING PACKAGING
If you are a downstream maintainer (packager) for a Linux distribution, If you are a downstream maintainer (packager) for a Linux
please avoid causing troubles. This section applies to you. distribution, please avoid causing troubles. This section
applies to you.
Send patches in regularly. Many patches made by vendors have been buggy, Avoid maintaining distribution specific patches. Send your
some quite severely so. Sending in a patch will at least get it reviewed, patches to upstream, where they are at least reviewed, if not
if not included. There is a procps-ng test suite that must be passed. included.
Forward all bug reports. If your bug database is public and busy enough
to bother with, please make this known. Follow Debian's lead in making
the bug database easy to comment on via email w/o need for an account.
Do not change the user interface. Many of the programs are intended to be Please forward bug reports. If your bug database is public and
compatible with Solaris, FreeBSD, AIX, IRIX, Tru64, and the UNIX standard. busy enough to bother with, please make this known. Follow
Your nice new command options WILL BE BROKEN as needed to ensure that Debian's lead in making the bug database easy to comment on via
procps-ng remains compatible with the rest of the world. Sysadmins hate to email without need for an account.
deal with incompatible behavior. If you need a new option, ask for it.
For normal packages, ensure that you do not add debugging flags For normal packages, ensure that you do not add debugging flags
to the CFLAGS variable. If debugging flags are present, the Makefile to the CFLAGS variable.
will avoid adding several optimizations that would interfere with gdb.
There should be no need to modify the Makefile. You can set variables UPSTREAM & BUG REPORTS
on the "make" command line or use "make -e" to pass variables from
the environment.
BUG REPORTS procps-ng <procps@freelists.org>
Email to procps@freelists.org.