Lunar Linux - User contributions [en]

Module Guidelines

2006-09-22T17:12:22Z

Jannis: /* DETAILS */

__TOC__

== 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 ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html 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.
* Avoid using the module's name in the SHORT field.
** e.g. instead of <code>SHORT="MyModle is an application designed to take over the world."</code> you should use <code>SHORT="an application designed to take over the world"</code>
** You are encouraged however to start the long description off with the modules name. So in the example above the long description might be "MyModule is a GTK+-2 application designed to take over the world. It features mind-control and cute, fuzzy kittens." (wrapped to 72 characters characters of course.) This way the output of [[lvu what]] is presented nicely to the user.
* Always align the equal signs (=) vertially within the file. "=" should be at character position 17, as this allows for the (optional) variable <code>SOURCE_DIRECTORY=</code> to be added later if needed and have it still be lined up with the rest of the content already in the file.
* Make sure to check whether a module is '''PSAFE''' or not. A lot of programs fail to build with parallel makes.

== 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 (non-optionally) "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX."
* Never put logic into this file. The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].
** Putting logic into DEPENDS, while it might seem clever, is a sure way to mess up Lunar's internal dependency handling mechanisms and commands such as [[lvu#leert|lvu leert]].
* If possible, always provide the means 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 compile in support for certain features, even if your computer has the necessary application/library installed to support that feature. Remember, choice is good.
* Always flow up each depends and optional_depends call with a && if there is another call to depends or optional_depends after it.
** This ensures that if the handling of the dependency fails for whatever reason, this module also fails to install.
** Remember that the last line of the file does ''not'' have && appended to it. Putting && at this location will cause a syntax error, effectivly breaking that module and anything depending on that module.

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

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-09-22T16:57:09Z

Jannis: /* DETAILS */

__TOC__

== 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 ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html 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.
* Avoid using the module's name in the SHORT field.
** e.g. instead of SHORT="MyModle is an application designed to take over the world." you should use SHORT="an application designed to take over the world"
** You are encouraged however to start the long description off with the modules name. So in the example above the long description might be "MyModule is a GTK+-2 application designed to take over the world. It features mind-control and cute, fuzzy kittens." (wrapped to 72 characters characters of course.) This way the output of [[lvu what]] is presented nicely to the user.
* Always align the equal signs (=) vertially within the file. "=" should be at character position 17, as this allows for the (optional) variable SOURCE_DIRECTORY= to be added later if needed and have it still be lined up with the rest of the content already in the file.
* Make sure to check whether a module is '''PSAFE''' or not. A lot of programs fail to build with parallel makes.

== 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 (non-optionally) "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX."
* Never put logic into this file. The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].
** Putting logic into DEPENDS, while it might seem clever, is a sure way to mess up Lunar's internal dependency handling mechanisms and commands such as [[lvu#leert|lvu leert]].
* If possible, always provide the means 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 compile in support for certain features, even if your computer has the necessary application/library installed to support that feature. Remember, choice is good.
* Always flow up each depends and optional_depends call with a && if there is another call to depends or optional_depends after it.
** This ensures that if the handling of the dependency fails for whatever reason, this module also fails to install.
** Remember that the last line of the file does ''not'' have && appended to it. Putting && at this location will cause a syntax error, effectivly breaking that module and anything depending on that module.

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

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-09-22T16:56:49Z

Jannis: /* DETAILS */

__TOC__

== 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 ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html 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.
* Avoid using the module's name in the SHORT field.
** e.g. instead of SHORT="MyModle is an application designed to take over the world." you should use SHORT="an application designed to take over the world"
** You are encouraged however to start the long description off with the modules name. So in the example above the long description might be "MyModule is a GTK+-2 application designed to take over the world. It features mind-control and cute, fuzzy kittens." (wrapped to 72 characters characters of course.) This way the output of [[lvu what]] is presented nicely to the user.
* Always align the equal signs (=) vertially within the file. "=" should be at character position 17, as this allows for the (optional) variable SOURCE_DIRECTORY= to be added later if needed and have it still be lined up with the rest of the content already in the file.
* Make sure to check if a module is '''PSAFE''' or not. A lot of programs fail to build with parallel makes.

== 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 (non-optionally) "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX."
* Never put logic into this file. The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].
** Putting logic into DEPENDS, while it might seem clever, is a sure way to mess up Lunar's internal dependency handling mechanisms and commands such as [[lvu#leert|lvu leert]].
* If possible, always provide the means 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 compile in support for certain features, even if your computer has the necessary application/library installed to support that feature. Remember, choice is good.
* Always flow up each depends and optional_depends call with a && if there is another call to depends or optional_depends after it.
** This ensures that if the handling of the dependency fails for whatever reason, this module also fails to install.
** Remember that the last line of the file does ''not'' have && appended to it. Putting && at this location will cause a syntax error, effectivly breaking that module and anything depending on that module.

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

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Writing

2006-08-28T15:35:26Z

Jannis: Guidelines link added.

__TOC__

Writing lunar [[modules]] can be extremely complex or very simple, and is analogous to performing the steps needed to install a [[package]] manually. However, there are so many variables you need to think of when writing modules, that it's hard to get them all right if you're new at writing modules.

==Before you start==

Take some time to think about ''why'' you want to make a new module. Also, there might be things to consider that would prevent you from writing a module at all. Here's some guidelines

* Check if the package is not already in [[moonbase]]. Nothing is worse then doing the same work double.
* Check the license. Perhaps the license is not compatible with lunar and your newly written module might never make it into moonbase due to licensing issues (''You can always submit your modules on the [[non-free modules]] website).
* Check the dependencies required for the module, and see if those also meet these requirements. Sometimes a module might take so much time to write that it's not worth it
* Check if you're not better off installing it manually or using a binary. Plenty of packages are so easy to install into your homedirectory and even though a module would be nice, it's often just easier to install it manually.

==Starting the module==

Find a good spot in [[moonbase]]. You should always work in the [[zlocal]] section. Your system [[moonbase]] is located in "/var/lib/lunar/moonbase".

cd /var/lib/lunar/moonbase/zlocal
mkdir mymodule
cd mymodule

Every module is defined as the group of files and directories including a [[DETAILS]] file in a directory. So we need a [[DETAILS]] file:

MODULE=mymodule
VERSION=1.0
SOURCE=$MODULE-$VERSION.tar.bz2
SOURCE_URL=http://my.site.org/files/
WEB_SITE=http://my.site.org/
ENTERED=20050808
UPDATED=20050808
SHORT="Makes module writing easy"
cat<<EOF
MyModule is a simple tool to explain module writing in
detail. It doesn't actually exist but is used as an example
for educational purposes
EOF

This is a basic [[DETAILS]] file with all required components. As you can see it's just plain shell code.

''All lunar module files are bash code. This means that you should pay special attention to shell meta characters and proper syntax''

This [[DETAILS]] file already can be all you need for writing a module, depending on the way "mymodule" needs to be compiled.

== Module Format ==

See [[Module Basics]] and [[Module Guidelines]] for detailled information about available module scripts and module examples.

Module Guidelines

2006-08-27T13:49:51Z

Jannis: /* Generic */

__TOC__

== Generic ==

* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' (or was it 79?) maximum width whenever possible (but always in [[DETAILS]]!).
* '''Respect the MAINTAINER''' value. Don't bump maintained modules unless you got the permission from the 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 ==

* If dependency ''B'' implies dependency ''A'', only add '''depends B''' (or '''optional_depends B ...''', depending on the dependency type).

== CONFLICTS ==

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-27T13:49:22Z

Jannis: Respect the maintainer rule added.

__TOC__

== Generic ==

* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' maximum width whenever possible (but always in [[DETAILS]]!).
* '''Respect the MAINTAINER''' value. Don't bump maintained modules unless you got the permission from the 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 ==

* If dependency ''B'' implies dependency ''A'', only add '''depends B''' (or '''optional_depends B ...''', depending on the dependency type).

== CONFLICTS ==

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-27T13:38:59Z

Jannis: Add recursive dependency rule

__TOC__

== Generic ==

* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' maximum width whenever possible (but always in [[DETAILS]]!).

== 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 ==

* If dependency ''B'' implies dependency ''A'', only add '''depends B''' (or '''optional_depends B ...''', depending on the dependency type).

== CONFLICTS ==

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-27T13:36:30Z

Jannis: /* DETAILS */

__TOC__

== Generic ==

* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' maximum width whenever possible (but always in [[DETAILS]]!).

== 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 ==

== CONFLICTS ==

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-27T13:34:59Z

Jannis: tar.bz2 rule added

__TOC__

== Generic ==

* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' maximum width whenever possible (but always in [[DETAILS]]!).

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

== DEPENDS ==

== CONFLICTS ==

== CONFIGURE ==

== PRE_BUILD ==

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

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-27T13:22:29Z

Jannis: Restructurized the markup.

Module Guidelines

2006-08-27T13:20:23Z

Jannis: /* Rules */

__TOC__

== Rules ==

=== Generic ===

* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' maximum width whenever possible (but always in [[DETAILS]]!).

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

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

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

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:19:02Z

Jannis: /* Rules */

__TOC__

== Rules ==

=== Generic ===

* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' maximum width whenever possible (but always in '''DETAILS'''!).

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

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

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

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:14:52Z

Jannis: Don't install files into the system after BUILD or devoke_installwatch.

__TOC__

== Rules ==

=== Generic ===

* '''Never''' use tabs. Use spaces instead.
* Use 72 columns maximum width whenever possible (but always in '''DETAILS'''!).

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

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

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

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:12:17Z

Jannis: /* Rules */

__TOC__

== Rules ==

=== Generic ===

* '''Never''' use tabs. Use spaces instead.
* Use 72 columns maximum width whenever possible (but always in '''DETAILS'''!).

=== DETAILS ===

* Use '''sha1:''' instead of '''md5:''' for '''SOURCE_VFY''' values
* Only insert your eMail address into the '''MAINTAINER''' field if you are a Lunar developer

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

=== BUILD ===

=== POST_BUILD ===

=== POST_INSTALL ===

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:12:03Z

Jannis: 72 columns rule added

__TOC__

== Rules ==

=== Generic ===

* '''Never''' use tabs. Use spaces instead.
* Use 72 columns maximum width whenever possible (but always in '''DETAILS'''!).

=== DETAILS ===

* Use '''sha1:''' instead of '''md5:''' for '''SOURCE_VFY''' values
* Only insert your eMail address into the '''MAINTAINER''' field if you are a Lunar developer

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

=== BUILD ===

=== POST_BUILD ===

=== POST_INSTALL ===

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:10:12Z

Jannis:

__TOC__

== Rules ==

=== Generic ===

* '''Never''' use tabs. Use spaces instead.

=== DETAILS ===

* Use '''sha1:''' instead of '''md5:''' for '''SOURCE_VFY''' values
* Only insert your eMail address into the '''MAINTAINER''' field if you are a Lunar developer

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

=== BUILD ===

=== POST_BUILD ===

=== POST_INSTALL ===

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:08:21Z

Jannis: Maintainer eMail address rule added

Module Guidelines

2006-08-27T13:06:57Z

Jannis: /* CONFLICTS */

__TOC__

== Rules ==

=== Generic ===

* '''Never''' use tabs. Use spaces instead.

=== DETAILS ===

* Use '''sha1:''' instead of '''md5:''' for '''SOURCE_VFY''' values

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

=== BUILD ===

=== POST_BUILD ===

=== POST_INSTALL ===

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:06:43Z

Jannis: /* DEPENDS */

Module Guidelines

2006-08-27T13:06:20Z

Jannis: SHA1 hint added

Module Guidelines

2006-08-27T13:04:19Z

Jannis: Added space between paragraphs.

__TOC__

== Rules ==

=== Generic ===

* '''Never''' use tabs. Use spaces instead.

=== DETAILS ===

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

=== BUILD ===

=== POST_BUILD ===

=== POST_INSTALL ===

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Guidelines

2006-08-27T13:02:42Z

Jannis: Use spaces rule added

Module Guidelines

2006-08-27T13:01:11Z

Jannis: Created the page skeleton

__TOC__

== Rules ==

=== Generic ===

=== DETAILS ===

=== DEPENDS ===

=== CONFLICTS ===

=== CONFIGURE ===

=== PRE_BUILD ===

=== BUILD ===

=== POST_BUILD ===

=== POST_INSTALL ===

=== PRE_REMOVE ===

=== POST_REMOVE ===

== Definition Of Good Style ==

Module Writing

2006-04-23T16:50:31Z

Jannis: /* Starting the module */

__TOC__

Writing lunar [[modules]] can be extremely complex or very simple, and is analogous to performing the steps needed to install a [[package]] manually. However, there are so many variables you need to think of when writing modules, that it's hard to get them all right if you're new at writing modules.

==Before you start==

Take some time to think about ''why'' you want to make a new module. Also, there might be things to consider that would prevent you from writing a module at all. Here's some guidelines

* Check if the package is not already in [[moonbase]]. Nothing is worse then doing the same work double.
* Check the license. Perhaps the license is not compatible with lunar and your newly written module might never make it into moonbase due to licensing issues (''You can always submit your modules on the [[non-free modules]] website).
* Check the dependencies required for the module, and see if those also meet these requirements. Sometimes a module might take so much time to write that it's not worth it
* Check if you're not better off installing it manually or using a binary. Plenty of packages are so easy to install into your homedirectory and even though a module would be nice, it's often just easier to install it manually.

==Starting the module==

Find a good spot in [[moonbase]]. You should always work in the [[zlocal]] section. Your system [[moonbase]] is located in "/var/lib/lunar/moonbase".

cd /var/lib/lunar/moonbase/zlocal
mkdir mymodule
cd mymodule

Every module is defined as the group of files and directories including a [[DETAILS]] file in a directory. So we need a [[DETAILS]] file:

MODULE=mymodule
VERSION=1.0
SOURCE=$MODULE-$VERSION.tar.bz2
SOURCE_URL=http://my.site.org/files/
WEB_SITE=http://my.site.org/
ENTERED=20050808
UPDATED=20050808
SHORT="Makes module writing easy"
cat<<EOF
MyModule is a simple tool to explain module writing in
detail. It doesn't actually exist but is used as an example
for educational purposes
EOF

This is a basic [[DETAILS]] file with all required components. As you can see it's just plain shell code.

''All lunar module files are bash code. This means that you should pay special attention to shell meta characters and proper syntax''

This [[DETAILS]] file already can be all you need for writing a module, depending on the way "mymodule" needs to be compiled.

== Module Format ==

See [[Module Basics]] for detailled information about available module scripts and module examples.