Module Guidelines

(Difference between revisions)

Jump to: navigation, search

Revision as of 20:19, 28 August 2006

These guidelines apply to all of a module's files.

Never use tabs. Use spaces instead.
Use 72 columns as a maximum width whenever possible (but always in the long description in the DETAILS file!).
Respect the MAINTAINER value. Don't modify maintained modules unless you first consult the listed maintainer.

Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
- The SHA1 algorithm has been shown to be less prone to key clashes than the MD5 algorithm.
Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
Prefer tar.bz2 over tar.gz tarballs (as it saves space/traffic) and prefer tar.gz over zip (or rar) packages.

Only list unique dependencies.
- That means that if the module you are building requires both "libX" and "libY" to properly compile/run but "libX" itself already requires (non-optionally) "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX."
If possible always provide a way to disable support for an optional dependency, even if that optional module is installed.
- That means if the application's ./configure script allows for a --disable-my-optional-depends you should include that switch when building your optional_depends line. This allows you to not-build in support for certain features, even if your computer has the necessary applications/libraries installed to support that feature. Choice is good.

Remember to add a CONFLICTS to both modules that conflict with each other.
When removing/renaming a module that had a CONFLICTS file, remember to remove/rename the conflict on all of the other modules this module conflicted with. Don't leave orphaned conflicts.

@@ Line 16: / Line 16: @@
 == DEPENDS ==
 *Only list unique dependencies.
-**That means that if the module you are building requires both "libX" and "libY" to properly compile/run but "libX" itself already requires "libY," you should only add "libX" as a dependency to your module.  This is because "libY" will automatically come along with "libX."
+**That means that if the module you are building requires both "libX" and "libY" to properly compile/run but "libX" itself already requires (non-optionally) "libY," you should only add "libX" as a dependency to your module.  This is because "libY" will automatically come along with "libX."
 *If possible always provide a way to disable support for an optional dependency, even if that optional module is installed.
 **That means if the application's ./configure script allows for a --disable-my-optional-depends you should include that switch when building your [[optional_depends]] line.  This allows you to not-build in support for certain features, even if your computer has the necessary applications/libraries installed to support that feature.  Choice is good.