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

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