mirror of the now-defunct rocklinux.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

83 lines
2.8 KiB

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, ...)