Module Guidelines

Generic

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.

DETAILS

• Use sha1: instead of md5: for SOURCE_VFY values.
• 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.

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."
• 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.

CONFLICTS

• 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.

BUILD

• Don't install files after calling devoke_installwatch.

POST_BUILD

• Don't install any files into the system.

POST_INSTALL

• Don't install any files into the system.