|
|
|
The ROCK Linux coding policy
|
|
|
|
Hello,
|
|
|
|
So you decided to help us with developing ROCK Linux? That's great! First you
|
|
should read this file carefully and than you should contact me per e-mail
|
|
(god@clifford.at) and tell me what you like to do or ask for open tasks.
|
|
|
|
happy hacking,
|
|
|
|
- Clifford (www.clifford.at)
|
|
|
|
-----
|
|
|
|
** ROCK Linux Philosophy
|
|
|
|
1. Keep it small and simple
|
|
|
|
ROCK Linux follows the KISS (keep it small and simple) concept. The most
|
|
packages are used as they are (without tons of patches). It contains
|
|
only packages which are used by most users. Packages which are normally
|
|
compiled by the user/admin are only included as source code and not as binary
|
|
package (e.g. Apache).
|
|
|
|
2. Packages sharing files
|
|
|
|
One file must be in exactly one package. It's not possible that two
|
|
packages share one file. If a package likes to install a file which is
|
|
already there because of another package, you need to patch the make file
|
|
or installation script or use the flistdel variable.
|
|
A few files are not owned by any package. These are e.g. /etc/ld.so.cache
|
|
or usr/share/info/dir. These files are re-generated by the /etc/cron.d/*
|
|
scripts (invoked by /usr/sbin/cron.run).
|
|
|
|
3. Package installation scripts
|
|
|
|
There are no scripts which can be started after the package has been
|
|
installed. This has a simple reason: what ever such a script could do
|
|
which can't be done by the build scripts would break rule 1.
|
|
|
|
4. Patches
|
|
|
|
A patch should always be submitted to the package maintainer if it could
|
|
be useful to the rest of the world - a bug should always be reported to the
|
|
package maintainer, if possible.
|
|
It's useless to fix a bug only for ROCK Linux and not letting the rest
|
|
of the community profit from the patch ...
|
|
|
|
5. System start up
|
|
|
|
A service/daemon should be only started on default if it's absolute
|
|
necessary. A fresh installed system should not open any network port or
|
|
configure a network interface. If the administrator needs it, he/she will
|
|
enable it!
|
|
|
|
6. Less packages
|
|
|
|
Don't split a package into subpackages everyone would install either none or
|
|
all of them. Don't mark a package as to be installed on default if a
|
|
standard server wouldn't need it. There will be no package included into
|
|
ROCK Linux that would only be used by a small number of users.
|
|
|
|
7. Be Terminal-Friendly
|
|
|
|
Don't make lines longer than 80 characters - if possible. 75 characters is
|
|
a good value. Also don't use upper-case letters or any special-characters in
|
|
package names. That's confusing people.
|
|
|
|
|
|
** Package Checklist
|
|
|
|
- puzzle.pz - Download and Build record(s)
|
|
|
|
- <pkg>.conf / default.conf - Build instructions
|
|
|
|
- <pkg>.desc / default.desc - Package description
|
|
|
|
- devlevel.txt - Should be equal to $devlv
|
|
|
|
- Is the Documentation installed at the right place
|
|
|
|
- Check the resulting file list (FHS, shares, temp-files, ...)
|