http://wiki.lunar-linux.org/api.php?action=feedcontributions&user=Cavalier&feedformat=atomLunar Linux - User contributions [en]2024-03-29T07:31:57ZUser contributionsMediaWiki 1.18.1http://wiki.lunar-linux.org/Module_BasicsModule Basics2013-10-26T18:38:28Z<p>Cavalier: /* The DEPENDS script */ Added optional preferred option</p>
<hr />
<div>__TOC__<br />
<br />
In ''Lunar'' parlance, software packages are called [[modules]]. The collection of all modules is the [[moonbase]], which is simply a directory (usually <code>/var/lib/lunar/moonbase/</code>) containing ''sections'' (i.e. directories) which in turn contain the [[module]] directories.<br />
<br />
A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in <code>/etc</code>. Some modules require only a [[DETAILS]] file, however this is only the case for a few of the modules in the entire moonbase. In each case, after [[DETAILS]], [[DEPENDS]], and [[CONFIGURE]], where a module can use lunar's default internal function(s), there is no need for a module-specific script.<br />
<br />
* [[DETAILS]] sets version, source URL(s) and other critical data<br />
* [[CONFLICTS]] specifies modules which must (will) be removed by module<br />
* [[CONFIGURE]] interactive script where build options can be set<br />
* [[DEPENDS]] specifies required and optional packages<br />
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal<br />
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs<br />
* [[BUILD]] runs necessary variations on: configure; make; make install<br />
* [[POST_BUILD]] install configuration scripts and data.<br />
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes<br />
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal<br />
<br />
'''Note:''' modules that require changes for 64-bit systems may also have DETAILS.x86_64, etc.<br />
<br />
<br />
== Package Build and Install Scripts ==<br />
<br />
The following scripts are used by [[Tools:lin|lin]] or indirectly by [[lunar]] when building modules.<br />
<br />
<br />
=== The DETAILS script ===<br />
<br />
Every module is required to have at least a [[DETAILS]] file. A minimal [[DETAILS]] may appear as follows: (<code>/var/lib/lunar/moonbase/editors/emacs/DETAILS</code>)<br />
<br />
MODULE=emacs<br />
VERSION=21.3<br />
SOURCE=$MODULE-$VERSION.tar.gz<br />
SOURCE_URL=$GNU_URL/$MODULE<br />
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki><br />
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980<br />
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki><br />
ENTERED=20010922<br />
UPDATED=20020529<br />
SHORT="the extensible, self-documenting real-time display editor"<br />
<br />
cat << EOF<br />
Emacs is the extensible, customizable, self-documenting real-time<br />
display editor. <br />
EOF<br />
<br />
Other SOURCE_URLS in lunar :<br />
* $GNOME_URL : GNOME mirrors<br />
* $GNU_URL : GNU mirrors<br />
* $KDE_URL : KDE mirrors<br />
* $SFORGE_URL : SourceForge mirrors<br />
* $LRESORT_URL : lunar-linux mirrors<br />
* $XFREE86_URL : XFree86 mirrors<br />
* $XORG_URL : x.org packages mirrors<br />
* $KERNEL_URL : kernel, kernel tools mirrors<br />
* $PATCH_URL : the place for *.patch or *.diff files which are not downloadable from other public hosts.<br />
** See [[Module Guidelines]] about creating patches for use in the BUILD file.<br />
** Such patches may be sent unpacked to Lunar developers mailing list: lunar-dev (at) lunar-linux (dot) org so that a Lunar developer can check it, pack it as *.bz2 archive then upload it to $PATCH_URL server.<br />
** Otherwise it may be copied to the module directory to be included as part of the '''lvu submit'''<br />
<br />
The use of _URL mirrors is very important because:<br />
* downloads are faster because mirror is usually very close to user<br />
* if any mirror server fails there is another one on list so user is not left with broken download<br />
* international Internet connections are less blocked<br />
<br />
Other optional fields :<br />
* If the application does not compile on more than one thread, add: PSAFE="no" or PSAFE=no<br />
* If the tarball is not extracting into the default $MODULE-$VERSION (e.g. emacs-21.7), add: SOURCE_DIRECTORY=$BUILD_DIRECTORY/"$MODULE"_"$VERSION"_src<br />
* If you want your name in the module and be listed as maintainer and like to be notified when somebody modifies the module, add : MAINTAINER=youremailadress<br />
* If you have more than one SOURCE_URL, list them as: SOURCE_URL[0]=, SOURCE_URL[1]=, SOURCE_URL[2]=, ...<br />
* If you have more than one SOURCE, list them as: SOURCE ,SOURCE2, SOURCE3, ... (don't forget to tell the BUILD script what to do with it...) and add a SOURCE2_URL as well...<br />
* If you want to force lunar to use the gcc4 compiler for this module, add: LUNAR_COMPILER=GCC_4_0 or GCC_3_4 for gcc3<br />
<br />
Update the UPDATED field only when you have added something that will change the compile behaviour, updated the version or you added configure options... don't change it just for outlining the DETAILS or BUILD or... file, so in general don't force ppl to recompile if all you did what tweaking around a bit...<br />
* Check [[Module_Guidelines]] for special handling of UPDATED for ''*-cvs'' or ''*-svn'' modules in '''zbeta'''.<br />
<br />
The SOURCE_VFY field can be used to check that the downloaded source file has not been corrupted, or changed, since the module was last updated. It should be omitted for modules that download snapshots of sources from svn, cvs, git repositories or similar because the sources could change between downloads.<br />
sha1 checksums are preferred, md5sums can be listed as SOURCE_VFY=md5: <br />
<br />
If you find a MAINTAINER field please respect this and notify the person listed there that you will or have updated his module.<br />
<br />
With comments, default values:<br />
<br />
MODULE=emacs # Module name, yes it's redundant<br />
VERSION=21.3 # Version, changes *often*<br />
SOURCE=$MODULE-$VERSION.tar.gz # Source filename<br />
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks<br />
# ($BUILD_DIRECTORY=/usr/src)<br />
SOURCE_URL[0]=$GNU_URL/$MODULE # Download URL<br />
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki> # Alternate URL(s)<br />
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980 # Sets sha1 hash or pgp/gpg sig url<br />
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more<br />
ENTERED=20010922 # First appearance in moonbase<br />
UPDATED=20020529 # Date of latest change.<br />
# Force update by setting this<br />
<br />
# The remaining lines are used for input to the 'lvu what' command<br />
# and are best copied from the source-maintainer's own description.<br />
<br />
SHORT="the extensible, self-documenting real-time display editor"<br />
<br />
cat << EOF<br />
Emacs is the extensible, customizable, self-documenting real-time<br />
display editor. <br />
EOF<br />
<br />
=== The DEPENDS script ===<br />
<br />
The [[DEPENDS]] script is essential to configuration management, and is the key to the overall operation of lunar. Dependencies should be exactly specified, preferably not assuming the presence of any other modules, while knowing the sub-dependencies of the modules which are added and not adding those explictly where not needed.<br />
<br />
'''Warning''' - Getting this right is difficult. Because the state of installed packages may vary widely, it's important to have a good understanding of what might be or not be installed on a target system.<br />
<br />
'''Note''' - By convention Lunar does not include the X Window System, xfree86 or XOrg, in any dependency. There are two reasons for this choice. First we expect that users must understand that to use a graphical application locally, the X Window System must be installed. Second, due to the sligtly unusual definition of client and server used by X11, it is often in fact possible to build graphical applications and tools for remote display, without the server components locally installed. At some future date we may elect to provide a client-only installation of xfree86.<br />
<br />
[[DEPENDS]] may include both required and optional dependencies. The '''depends''' function statement simply determines one required package. The '''optional_depends''' function is a little more complex. It consists of the required package, necessary --options to give to <code>./configure</code> for yes and no respectively, an explanatory comment telling the user the purpose of the option being presented, and an optional preferred choice. Normally the preferred choice depends on the modules state of the required package, this option can change that behaviour and always default to y or n. A typical [[DEPENDS]] file might appear as follows: (<code>/var/lib/lunar/moonbase/devel/subversion/DEPENDS</code>)<br />
<br />
depends zlib<br />
depends openssl<br />
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"<br />
# ^ ^ ^ ^<br />
# | | | |<br />
# optional package if "Y" if "N" explanatory comment<br />
# { ./configure strings }<br />
<br />
Many old modules use '&&' in [[DEPENDS]] to be consistent with [[BUILD]] files, but the '&&' delimiter is not required and new [[DEPENDS]] files should not use it.<br />
<br />
* '''Important''' - You may not use '''if module_installed...''' or other general bash programming in the [[DEPENDS]] file to handle conditional dependencies. This is to keep the dependency tracking code in the lunar tools as simple and fast as possible.<br />
<br />
'''Aliases'''<br />
<br />
Aliases are a mean to select a generic module. When you need a functionnality that can be provided by two or more softwares, you can select one of them to provide a correct dependency.<br />
<br />
Example /var/lib/lunar/moonbase/aliases:<br />
<code><br />
%APACHE:apache apache2 apache-mod_ssl<br />
%FAM:fam gamin<br />
%GECKO_RENDERER: firefox thunderbird mozilla<br />
%GHOSTSCRIPT:espgs ghostscript<br />
%MTA:postfix exim sendmail esmtp<br />
%SLANG:slang slang2<br />
%X:XOrg XOrg-test xfree86 xfree86-beta<br />
%XMLRENDERER: libxml2 expat<br />
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde<br />
</code><br />
<br />
For example you can choose %X instead of XOrg in a module that would depends on any X server:<br />
<code><br />
depends %X<br />
</code><br />
<br />
=== The CONFLICTS script ===<br />
<br />
This script is simply used to specify modules which will be removed when a given module is installed. An example would be: (<code>/var/lib/lunar/moonbase/editors/elvis/CONFLICTS</code>)<br />
<br />
conflicts vim<br />
<br />
<br />
=== The CONFIGURE script ===<br />
<br />
The [[CONFIGURE]] script is used to collect interactive input from the user on optional parameters for the software build. use the '''query''' function and provide a default answer to each question. The results of the answers are then used to store configuration variables needed in configuration state files. An a simple example might be: (<code>/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE</code>)<br />
<br />
if ! grep -q CONFIGURED $MODULE_CONFIG ; then<br />
if query "Enable experimental external HKP keyserver interface? " n ; then<br />
OPTS="$OPTS --enable-external-hkp"<br />
fi<br />
echo 'CONFIGURED="y"' >> $MODULE_CONFIG<br />
echo 'OPTS='\"$OPTS\" >> $MODULE_CONFIG<br />
fi<br />
<br />
Another way is using '''mquery''' like the lilo module does:<br />
<br />
mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y<br />
<br />
mquery ENABLE_FOO "Enable foo?" n "--enable-foo --enable-foo2" "--disable-foo --disable-foo2"<br />
<br />
Where "No" would be the default answer for the user. When he chooses to enable-foo, then answer "yes" would be stored in the ENABLE_FOO variable and --enable-foo and --enable-foo2 will get added to the ./configure command in the BUILD script.<br />
<br />
=== The PRE_BUILD script ===<br />
<br />
[[PRE_BUILD]] is used where special processing is needed before undertaking the actual build steps. Typical requirements include unpacking multiple sources, creating necessary system or source-tree direcotries and applying source patches. And example would be: (<code>/var/lib/lunar/moonbase/doc-tools/html2db/PRE_BUILD</code>)<br />
<br />
mk_source_dir $SOURCE_DIRECTORY &&<br />
unpack $SOURCE &&<br />
cd $MODULE<br />
unpack $SOURCE2<br />
cd tidy<br />
patch_it $SOURCE_CACHE/$SOURCE3 0<br />
cd /usr/src/$MODULE<br />
<br />
<br />
=== The BUILD script ===<br />
<br />
[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:<br />
<br />
Function '''default_build()''' calls '''default_config''' which executes:<br />
<br />
./configure --build=$BUILD \<br />
--prefix=/usr \<br />
--sysconfdir=/etc \<br />
--localstatedir=/var \<br />
--infodir=/usr/share/info \<br />
--mandir=/usr/share/man \<br />
$OPTS<br />
<br />
Next, '''default_build()''' calls '''default_make''' which executes:<br />
<br />
make &&<br />
prepare_install &&<br />
make install<br />
<br />
The '''prepare_install''' should only be called immediately before the '''make install''' phase, so that the package management system only tracks the installed files and not any intermediate build files.<br />
<br />
2011-02-20: Be aware that several modules in the moonbase appear to get this wrong, so take care!<br />
<br />
If you have modules from git,svn or cvs, the ''configure'' script is missing most of the time. You can then use the ''default_cvs_build()'' function. The commands run are:<br />
<br />
./autogen.sh --prefix=/usr <br />
<br />
it will then call ''default_make()'' <br />
<br />
Where this build configuration does not work, the [[BUILD]] script is used to provide the needed steps. About 75% of modules need a [[BUILD]] script. Two examples include: (<code>/var/lib/lunar/moonbase/archive/gzip/BUILD</code>)<br />
<br />
./configure --build=$BUILD \<br />
--prefix=/usr \<br />
--bindir=/bin \<br />
--infodir=/usr/share/info \<br />
--mandir=/usr/share/man &&<br />
make &&<br />
prepare_install &&<br />
make bindir=/bin install<br />
<br />
and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)<br />
<br />
cd $SOURCE_DIRECTORY &&<br />
sedit 's/usr.local/usr/' Makefile &&<br />
sedit 's/= man/= share\/man/' Makefile &&<br />
sedit 's/ucb/bin/' Makefile &&<br />
sedit 's/= termlib/= ncurses/' Makefile &&<br />
make &&<br />
prepare_install &&<br />
make install<br />
<br />
The first example is a build which needs non-standard 'configure' and 'make install' commands. The second is a build which does not use gnu auto-tools' 'configure' script.<br />
<br />
In the examples above, the [[BUILD]] scripts contain multiple commands separated by '&&' to ensure that execution stops as soon as any command fails. The '&&' are 'and' operations: the command after the '&&' will only be run if the one before the '&&' completed successfully. The use of '&&' is '''required''' in multi-command [[BUILD]] scripts.<br />
<br />
=== The POST_BUILD script ===<br />
<br />
[[POST_BUILD]] runs in place of the '''default_post_build''' routine which is used to install minor documentation and transfer/enable initialization scripts and similar system data, mostly into <code>/etc</code>. <br />
<br />
[[POST_BUILD]] script usage is '''deprecated'''. You should install your config files in [[BUILD]] (remember not to overwrite previous config files!) or install defaults from [[POST_INSTALL]] (again, do not overwrite present files!). The ability to use a [[POST_BUILD]] script is purely for certain internal functions.<br />
<br />
=== The POST_INSTALL script ===<br />
<br />
[[POST_INSTALL]] has no equivalent functions, and is run to handle post-installation work in a general manner. An example is: (<code>/var/lib/lunar/moonbase/compilers/gcc/POST_INSTALL</code>)<br />
<br />
cd /usr/lib/gcc-lib/$BUILD/$VERSION &&<br />
ln -sf /usr/bin/cpp cpp &&<br />
cd /lib/ &&<br />
ln -sf /usr/bin/cpp cpp && <br />
if [ ! -e /usr/bin/cc ] ; then<br />
ln -s gcc /usr/bin/cc<br />
fi<br />
<br />
As in the [[BUILD]] scripts, the '&&' represent 'and' operations, but their use in [[POST_INSTALL]] scripts is '''preferred''' rather than '''required'''.<br />
<br />
== Package Removal Scripts ==<br />
<br />
Module removal is handled by [[lrm]]. Because installation is monitored and backup tarballs are created using installwatch, most of package removal is handled automatically using the logs created by installwatch. However we provide for additional actions to be taken through the [[PRE_REMOVE]] and [[POST_REMOVE]] scripts.<br />
<br />
<br />
=== The PRE_REMOVE script ===<br />
<br />
[[PRE_REMOVE]] is needed to execute any tasks needed prior to the main task of removing all files installed by the module. An example would be: (<code>/var/lib/lunar/moonbase/mail/docbook-3.1/PRE_REMOVE</code>)<br />
<br />
CENTRALIZED=/etc/sgml/catalog<br />
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION<br />
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog<br />
<br />
<br />
=== The POST_REMOVE Script ===<br />
<br />
[[POST_REMOVE]] may be used to remove data not tracked by installwatch and to correctly adjust remaining configuration files and data. Examples would include: (<code>/var/lib/lunar/moonbase/devel/binutils/POST_REMOVE</code>)<br />
<br />
install-info --delete as --info-dir /usr/info<br />
install-info --delete bfd --info-dir /usr/info<br />
install-info --delete binutils --info-dir /usr/info<br />
install-info --delete configure --info-dir /usr/info<br />
install-info --delete gasp --info-dir /usr/info<br />
install-info --delete gprof --info-dir /usr/info<br />
install-info --delete ld --info-dir /usr/info<br />
<br />
or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)<br />
<br />
if module_installed apache; then<br />
cp /etc/httpd/httpd.conf /tmp/httpd.conf<br />
grep -v "LoadModule php4_module" /tmp/httpd.conf |<br />
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf<br />
rm -f /tmp/httpd.conf<br />
elif module_installed apache_mod_ssl; then<br />
cp /etc/httpsd/httpd.conf /tmp/httpd.conf<br />
grep -v "LoadModule php4_module" /tmp/httpd.conf |<br />
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf<br />
rm -f /tmp/httpd.conf<br />
fi</div>Cavalierhttp://wiki.lunar-linux.org/Module_BasicsModule Basics2013-10-26T18:22:58Z<p>Cavalier: /* The DETAILS script */ Changed SOURCE1_URL</p>
<hr />
<div>__TOC__<br />
<br />
In ''Lunar'' parlance, software packages are called [[modules]]. The collection of all modules is the [[moonbase]], which is simply a directory (usually <code>/var/lib/lunar/moonbase/</code>) containing ''sections'' (i.e. directories) which in turn contain the [[module]] directories.<br />
<br />
A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in <code>/etc</code>. Some modules require only a [[DETAILS]] file, however this is only the case for a few of the modules in the entire moonbase. In each case, after [[DETAILS]], [[DEPENDS]], and [[CONFIGURE]], where a module can use lunar's default internal function(s), there is no need for a module-specific script.<br />
<br />
* [[DETAILS]] sets version, source URL(s) and other critical data<br />
* [[CONFLICTS]] specifies modules which must (will) be removed by module<br />
* [[CONFIGURE]] interactive script where build options can be set<br />
* [[DEPENDS]] specifies required and optional packages<br />
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal<br />
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs<br />
* [[BUILD]] runs necessary variations on: configure; make; make install<br />
* [[POST_BUILD]] install configuration scripts and data.<br />
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes<br />
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal<br />
<br />
'''Note:''' modules that require changes for 64-bit systems may also have DETAILS.x86_64, etc.<br />
<br />
<br />
== Package Build and Install Scripts ==<br />
<br />
The following scripts are used by [[Tools:lin|lin]] or indirectly by [[lunar]] when building modules.<br />
<br />
<br />
=== The DETAILS script ===<br />
<br />
Every module is required to have at least a [[DETAILS]] file. A minimal [[DETAILS]] may appear as follows: (<code>/var/lib/lunar/moonbase/editors/emacs/DETAILS</code>)<br />
<br />
MODULE=emacs<br />
VERSION=21.3<br />
SOURCE=$MODULE-$VERSION.tar.gz<br />
SOURCE_URL=$GNU_URL/$MODULE<br />
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki><br />
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980<br />
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki><br />
ENTERED=20010922<br />
UPDATED=20020529<br />
SHORT="the extensible, self-documenting real-time display editor"<br />
<br />
cat << EOF<br />
Emacs is the extensible, customizable, self-documenting real-time<br />
display editor. <br />
EOF<br />
<br />
Other SOURCE_URLS in lunar :<br />
* $GNOME_URL : GNOME mirrors<br />
* $GNU_URL : GNU mirrors<br />
* $KDE_URL : KDE mirrors<br />
* $SFORGE_URL : SourceForge mirrors<br />
* $LRESORT_URL : lunar-linux mirrors<br />
* $XFREE86_URL : XFree86 mirrors<br />
* $XORG_URL : x.org packages mirrors<br />
* $KERNEL_URL : kernel, kernel tools mirrors<br />
* $PATCH_URL : the place for *.patch or *.diff files which are not downloadable from other public hosts.<br />
** See [[Module Guidelines]] about creating patches for use in the BUILD file.<br />
** Such patches may be sent unpacked to Lunar developers mailing list: lunar-dev (at) lunar-linux (dot) org so that a Lunar developer can check it, pack it as *.bz2 archive then upload it to $PATCH_URL server.<br />
** Otherwise it may be copied to the module directory to be included as part of the '''lvu submit'''<br />
<br />
The use of _URL mirrors is very important because:<br />
* downloads are faster because mirror is usually very close to user<br />
* if any mirror server fails there is another one on list so user is not left with broken download<br />
* international Internet connections are less blocked<br />
<br />
Other optional fields :<br />
* If the application does not compile on more than one thread, add: PSAFE="no" or PSAFE=no<br />
* If the tarball is not extracting into the default $MODULE-$VERSION (e.g. emacs-21.7), add: SOURCE_DIRECTORY=$BUILD_DIRECTORY/"$MODULE"_"$VERSION"_src<br />
* If you want your name in the module and be listed as maintainer and like to be notified when somebody modifies the module, add : MAINTAINER=youremailadress<br />
* If you have more than one SOURCE_URL, list them as: SOURCE_URL[0]=, SOURCE_URL[1]=, SOURCE_URL[2]=, ...<br />
* If you have more than one SOURCE, list them as: SOURCE ,SOURCE2, SOURCE3, ... (don't forget to tell the BUILD script what to do with it...) and add a SOURCE2_URL as well...<br />
* If you want to force lunar to use the gcc4 compiler for this module, add: LUNAR_COMPILER=GCC_4_0 or GCC_3_4 for gcc3<br />
<br />
Update the UPDATED field only when you have added something that will change the compile behaviour, updated the version or you added configure options... don't change it just for outlining the DETAILS or BUILD or... file, so in general don't force ppl to recompile if all you did what tweaking around a bit...<br />
* Check [[Module_Guidelines]] for special handling of UPDATED for ''*-cvs'' or ''*-svn'' modules in '''zbeta'''.<br />
<br />
The SOURCE_VFY field can be used to check that the downloaded source file has not been corrupted, or changed, since the module was last updated. It should be omitted for modules that download snapshots of sources from svn, cvs, git repositories or similar because the sources could change between downloads.<br />
sha1 checksums are preferred, md5sums can be listed as SOURCE_VFY=md5: <br />
<br />
If you find a MAINTAINER field please respect this and notify the person listed there that you will or have updated his module.<br />
<br />
With comments, default values:<br />
<br />
MODULE=emacs # Module name, yes it's redundant<br />
VERSION=21.3 # Version, changes *often*<br />
SOURCE=$MODULE-$VERSION.tar.gz # Source filename<br />
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks<br />
# ($BUILD_DIRECTORY=/usr/src)<br />
SOURCE_URL[0]=$GNU_URL/$MODULE # Download URL<br />
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki> # Alternate URL(s)<br />
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980 # Sets sha1 hash or pgp/gpg sig url<br />
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more<br />
ENTERED=20010922 # First appearance in moonbase<br />
UPDATED=20020529 # Date of latest change.<br />
# Force update by setting this<br />
<br />
# The remaining lines are used for input to the 'lvu what' command<br />
# and are best copied from the source-maintainer's own description.<br />
<br />
SHORT="the extensible, self-documenting real-time display editor"<br />
<br />
cat << EOF<br />
Emacs is the extensible, customizable, self-documenting real-time<br />
display editor. <br />
EOF<br />
<br />
=== The DEPENDS script ===<br />
<br />
The [[DEPENDS]] script is essential to configuration management, and is the key to the overall operation of lunar. Dependencies should be exactly specified, preferably not assuming the presence of any other modules, while knowing the sub-dependencies of the modules which are added and not adding those explictly where not needed.<br />
<br />
'''Warning''' - Getting this right is difficult. Because the state of installed packages may vary widely, it's important to have a good understanding of what might be or not be installed on a target system.<br />
<br />
'''Note''' - By convention Lunar does not include the X Window System, xfree86 or XOrg, in any dependency. There are two reasons for this choice. First we expect that users must understand that to use a graphical application locally, the X Window System must be installed. Second, due to the sligtly unusual definition of client and server used by X11, it is often in fact possible to build graphical applications and tools for remote display, without the server components locally installed. At some future date we may elect to provide a client-only installation of xfree86.<br />
<br />
[[DEPENDS]] may include both required and optional dependencies. The '''depends()''' function statement simply determines one required package. The optional_depends function is a little more complex. It consists of the required package, necessary --options to give to <code>./configure</code> for yes and no respectively, and an explanatory comment telling the user the purpose of the option being presented. A typical [[DEPENDS]] file might appear as follows: (<code>/var/lib/lunar/moonbase/devel/subversion/DEPENDS</code>)<br />
<br />
depends zlib<br />
depends openssl<br />
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"<br />
# ^ ^ ^ ^<br />
# | | | |<br />
# optional package if "Y" if "N" explanatory comment<br />
# { ./configure strings }<br />
<br />
Many old modules use '&&' in [[DEPENDS]] to be consistent with [[BUILD]] files, but the '&&' delimiter is not required and new [[DEPENDS]] files should not use it.<br />
<br />
* '''Important''' - You may not use '''if module_installed...''' or other general bash programming in the [[DEPENDS]] file to handle conditional dependencies. This is to keep the dependency tracking code in the lunar tools as simple and fast as possible.<br />
<br />
'''Aliases'''<br />
<br />
Aliases are a mean to select a generic module. When you need a functionnality that can be provided by two or more softwares, you can select one of them to provide a correct dependency.<br />
<br />
Example /var/lib/lunar/moonbase/aliases:<br />
<code><br />
%APACHE:apache apache2 apache-mod_ssl<br />
%FAM:fam gamin<br />
%GECKO_RENDERER: firefox thunderbird mozilla<br />
%GHOSTSCRIPT:espgs ghostscript<br />
%MTA:postfix exim sendmail esmtp<br />
%SLANG:slang slang2<br />
%X:XOrg XOrg-test xfree86 xfree86-beta<br />
%XMLRENDERER: libxml2 expat<br />
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde<br />
</code><br />
<br />
For example you can choose %X instead of XOrg in a module that would depends on any X server:<br />
<code><br />
depends %X<br />
</code><br />
<br />
=== The CONFLICTS script ===<br />
<br />
This script is simply used to specify modules which will be removed when a given module is installed. An example would be: (<code>/var/lib/lunar/moonbase/editors/elvis/CONFLICTS</code>)<br />
<br />
conflicts vim<br />
<br />
<br />
=== The CONFIGURE script ===<br />
<br />
The [[CONFIGURE]] script is used to collect interactive input from the user on optional parameters for the software build. use the '''query''' function and provide a default answer to each question. The results of the answers are then used to store configuration variables needed in configuration state files. An a simple example might be: (<code>/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE</code>)<br />
<br />
if ! grep -q CONFIGURED $MODULE_CONFIG ; then<br />
if query "Enable experimental external HKP keyserver interface? " n ; then<br />
OPTS="$OPTS --enable-external-hkp"<br />
fi<br />
echo 'CONFIGURED="y"' >> $MODULE_CONFIG<br />
echo 'OPTS='\"$OPTS\" >> $MODULE_CONFIG<br />
fi<br />
<br />
Another way is using '''mquery''' like the lilo module does:<br />
<br />
mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y<br />
<br />
mquery ENABLE_FOO "Enable foo?" n "--enable-foo --enable-foo2" "--disable-foo --disable-foo2"<br />
<br />
Where "No" would be the default answer for the user. When he chooses to enable-foo, then answer "yes" would be stored in the ENABLE_FOO variable and --enable-foo and --enable-foo2 will get added to the ./configure command in the BUILD script.<br />
<br />
=== The PRE_BUILD script ===<br />
<br />
[[PRE_BUILD]] is used where special processing is needed before undertaking the actual build steps. Typical requirements include unpacking multiple sources, creating necessary system or source-tree direcotries and applying source patches. And example would be: (<code>/var/lib/lunar/moonbase/doc-tools/html2db/PRE_BUILD</code>)<br />
<br />
mk_source_dir $SOURCE_DIRECTORY &&<br />
unpack $SOURCE &&<br />
cd $MODULE<br />
unpack $SOURCE2<br />
cd tidy<br />
patch_it $SOURCE_CACHE/$SOURCE3 0<br />
cd /usr/src/$MODULE<br />
<br />
<br />
=== The BUILD script ===<br />
<br />
[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:<br />
<br />
Function '''default_build()''' calls '''default_config''' which executes:<br />
<br />
./configure --build=$BUILD \<br />
--prefix=/usr \<br />
--sysconfdir=/etc \<br />
--localstatedir=/var \<br />
--infodir=/usr/share/info \<br />
--mandir=/usr/share/man \<br />
$OPTS<br />
<br />
Next, '''default_build()''' calls '''default_make''' which executes:<br />
<br />
make &&<br />
prepare_install &&<br />
make install<br />
<br />
The '''prepare_install''' should only be called immediately before the '''make install''' phase, so that the package management system only tracks the installed files and not any intermediate build files.<br />
<br />
2011-02-20: Be aware that several modules in the moonbase appear to get this wrong, so take care!<br />
<br />
If you have modules from git,svn or cvs, the ''configure'' script is missing most of the time. You can then use the ''default_cvs_build()'' function. The commands run are:<br />
<br />
./autogen.sh --prefix=/usr <br />
<br />
it will then call ''default_make()'' <br />
<br />
Where this build configuration does not work, the [[BUILD]] script is used to provide the needed steps. About 75% of modules need a [[BUILD]] script. Two examples include: (<code>/var/lib/lunar/moonbase/archive/gzip/BUILD</code>)<br />
<br />
./configure --build=$BUILD \<br />
--prefix=/usr \<br />
--bindir=/bin \<br />
--infodir=/usr/share/info \<br />
--mandir=/usr/share/man &&<br />
make &&<br />
prepare_install &&<br />
make bindir=/bin install<br />
<br />
and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)<br />
<br />
cd $SOURCE_DIRECTORY &&<br />
sedit 's/usr.local/usr/' Makefile &&<br />
sedit 's/= man/= share\/man/' Makefile &&<br />
sedit 's/ucb/bin/' Makefile &&<br />
sedit 's/= termlib/= ncurses/' Makefile &&<br />
make &&<br />
prepare_install &&<br />
make install<br />
<br />
The first example is a build which needs non-standard 'configure' and 'make install' commands. The second is a build which does not use gnu auto-tools' 'configure' script.<br />
<br />
In the examples above, the [[BUILD]] scripts contain multiple commands separated by '&&' to ensure that execution stops as soon as any command fails. The '&&' are 'and' operations: the command after the '&&' will only be run if the one before the '&&' completed successfully. The use of '&&' is '''required''' in multi-command [[BUILD]] scripts.<br />
<br />
=== The POST_BUILD script ===<br />
<br />
[[POST_BUILD]] runs in place of the '''default_post_build''' routine which is used to install minor documentation and transfer/enable initialization scripts and similar system data, mostly into <code>/etc</code>. <br />
<br />
[[POST_BUILD]] script usage is '''deprecated'''. You should install your config files in [[BUILD]] (remember not to overwrite previous config files!) or install defaults from [[POST_INSTALL]] (again, do not overwrite present files!). The ability to use a [[POST_BUILD]] script is purely for certain internal functions.<br />
<br />
=== The POST_INSTALL script ===<br />
<br />
[[POST_INSTALL]] has no equivalent functions, and is run to handle post-installation work in a general manner. An example is: (<code>/var/lib/lunar/moonbase/compilers/gcc/POST_INSTALL</code>)<br />
<br />
cd /usr/lib/gcc-lib/$BUILD/$VERSION &&<br />
ln -sf /usr/bin/cpp cpp &&<br />
cd /lib/ &&<br />
ln -sf /usr/bin/cpp cpp && <br />
if [ ! -e /usr/bin/cc ] ; then<br />
ln -s gcc /usr/bin/cc<br />
fi<br />
<br />
As in the [[BUILD]] scripts, the '&&' represent 'and' operations, but their use in [[POST_INSTALL]] scripts is '''preferred''' rather than '''required'''.<br />
<br />
== Package Removal Scripts ==<br />
<br />
Module removal is handled by [[lrm]]. Because installation is monitored and backup tarballs are created using installwatch, most of package removal is handled automatically using the logs created by installwatch. However we provide for additional actions to be taken through the [[PRE_REMOVE]] and [[POST_REMOVE]] scripts.<br />
<br />
<br />
=== The PRE_REMOVE script ===<br />
<br />
[[PRE_REMOVE]] is needed to execute any tasks needed prior to the main task of removing all files installed by the module. An example would be: (<code>/var/lib/lunar/moonbase/mail/docbook-3.1/PRE_REMOVE</code>)<br />
<br />
CENTRALIZED=/etc/sgml/catalog<br />
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION<br />
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog<br />
<br />
<br />
=== The POST_REMOVE Script ===<br />
<br />
[[POST_REMOVE]] may be used to remove data not tracked by installwatch and to correctly adjust remaining configuration files and data. Examples would include: (<code>/var/lib/lunar/moonbase/devel/binutils/POST_REMOVE</code>)<br />
<br />
install-info --delete as --info-dir /usr/info<br />
install-info --delete bfd --info-dir /usr/info<br />
install-info --delete binutils --info-dir /usr/info<br />
install-info --delete configure --info-dir /usr/info<br />
install-info --delete gasp --info-dir /usr/info<br />
install-info --delete gprof --info-dir /usr/info<br />
install-info --delete ld --info-dir /usr/info<br />
<br />
or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)<br />
<br />
if module_installed apache; then<br />
cp /etc/httpd/httpd.conf /tmp/httpd.conf<br />
grep -v "LoadModule php4_module" /tmp/httpd.conf |<br />
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf<br />
rm -f /tmp/httpd.conf<br />
elif module_installed apache_mod_ssl; then<br />
cp /etc/httpsd/httpd.conf /tmp/httpd.conf<br />
grep -v "LoadModule php4_module" /tmp/httpd.conf |<br />
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf<br />
rm -f /tmp/httpd.conf<br />
fi</div>Cavalierhttp://wiki.lunar-linux.org/GitForLunarDevsGitForLunarDevs2013-06-09T21:54:57Z<p>Cavalier: Rewritten to the new github workflow</p>
<hr />
<div>== GITHUB work flow ==<br />
Requirements a github account and a mindset to use git and github.<br />
To be able to push changes to github it is recommended by github to use https. But some prefer using ssh authentication keys. See https://help.github.com/articles/generating-ssh-keys<br />
Have your git config setup correct with your ''user.name'' and ''user.email''<br />
git config --global user.name "John Doe"<br />
git config --global user.name "john@doe.net"<br />
<br />
=== Personal repo to work in ===<br />
To be able to send pull requests you need a personal repo on github which is a fork of the repo you want to work on.<br />
<br />
On github navigate to https://github.com/lunar-linux and select the repo you wan to work on. click on the fork button near top right.<br />
Now you have your personal repo in github. Next step is to create a clone the repo to you pc. On github select your repo and you can see the pull url you need to use to have read+write access<br />
<br />
git clone git@github.com/<username>/<reponame><br />
<br />
For more information see https://help.github.com/articles/fork-a-repo<br />
<br />
'''note:''' all the next command assume you are in your local repo directory.<br />
<br />
This repo is up to date with lunar-linux repo only because you just forked it. So the next step is to setup a upstream branch to help with keeping your repo up to date.<br />
<br />
git remote add upstream git://github.com/lunar-linux/<reponame><br />
git checkout -b upstream_master upstream/master<br />
<br />
'''note:''' with '''git checkout''' you can switch between branches. So, you'll end up in the ''upstream_master'' branch. To switch back to master: '''git checkout master'''<br />
<br />
=== Keeping your personal repo up to date ===<br />
After some time commits will have been push to lunar-linux/<reponame> and you want to have them in you repo too. This is where the ''upstream_master'' branch comes in useful.<br />
<br />
git checkout upstream_master<br />
git pull<br />
<br />
'''note:''' In this guide there are a lot of '''git checkout''' <branchname> this it not required if you are already in that branch.<br />
<br />
'''note:''' Git could complain it you try to switch to another branch if you have local modifications. If you are switching temporarily you can use git stash to store your changes.<br />
<br />
git stash<br />
<...><br />
git checkout <WIP branch><br />
git stash pop<br />
<br />
Now that your ''upstream_master'' is up to date you need to get these changes in your other branches. That would be at least ''master''. But you can repeat these instructions for every branch you have. Just replace ''master'' with <branchname> and optionally replace ''upstream_master'' with ''master''.<br />
<br />
git checkout master<br />
git merge upstream_master<br />
<br />
Now you have this locally you can push this to you personal github.<br />
<br />
git checkout master<br />
git push<br />
<br />
=== Working with branches ===<br />
For the pull requests it is easier if you work with a concept called feature branches. In this concept you don't make changes directly into ''master'', but rather you create a branch and make your changes there. These changes can contain one or more commits. Unless you work with local only branches you won't merge these branches back into ''master'' yourself. These branches will be merged back into ''master'' when they are pulled into lunar-linux/<repo> and you update your personal repo.<br />
<br />
lunar-linux master: --- A ---- D --- [BC]M --- E ------------<br />
\ / \<br />
personal dev branch: \ B --- C \<br />
\ / \<br />
local master: ------ [A] ------------------ [BDCME] ---<br />
<br />
A-E are normal commits.<br />
M is a merge commit.<br />
Commits between [] is only pulled objects. This doesn't change these commits.<br />
<br />
'''note:''' This means you can have multiple branches in parallel with all unrelated changes. Sometimes you need to have an extra local branch to merge multiple branches in to test some interactions. Since local branches can just be deleted with no fuzz, this can save you from polluting your ''master'' branch.<br />
<br />
'''note:''' One feature branch doesn't mean one module change. This could contain multiple modules. These module changes are mostly related. Like changes to all dependencies when you bump a module.<br />
<br />
=== Creating a development branch ===<br />
There are two types of development branches. Local and remote branches. Local branches only exist in your local repo. These are just for you and you can handle them as you like. Remote branches are branches on your personal github. These branches are public and might be used by others. This has some limitations but that is out of the scope of this guide.<br />
<br />
To create a remote branch you must first create it locally. It is most common to start a branch from your up to date local ''master''.<br />
<br />
git checkout master<br />
git checkout -b <branchname><br />
<br />
Now you end up in you new branch. Make you changes commit them. Make some more commits, maybe.<br />
Now you want your local branch to be on your personal github for the first time for this branch.<br />
<br />
git checkout <branchname><br />
git push --set-upstream origin <local-branchname>:<remote-branchname><br />
<br />
'''note:''' In many cases you want the local and remote branch name to be the same.<br />
<br />
On the remote branch you can send a pull request or others can see what you have done so far.<br />
If your branch is not complete and you made some extra commits on the branch in your local repo. You want to push these changes to your personal github too.<br />
<br />
git checkout <branchname><br />
git push<br />
<br />
=== Working with pull requests ===<br />
It is preferred to send pull request even if you have access to lunar-linux/<repo>. By sending a pull request there is another developer looking at your changes. And if you have some doubts you can add a comment to the pull request.<br />
<br />
There is no point in sending pull requests is you are going to accept them your self. This will only generate extra noise. For small changes you can omit a pull request. For bigger changes let another developer pull in your request.<br />
<br />
=== Sending a pull request ===<br />
The easiest way to set a pull request in github is using feature branches. On github in you personal repo. Select the branch you want. And click on the pull request button on the top right.<br />
You will be prompted with a form and some fields might already be filled. You can add some extra description if care needs to be taken for the merge for example.<br />
With the commits and changes button you can see what your pull request will contain.<br />
When you're ready click the send pull request button on the bottom right.<br />
For more information see https://help.github.com/articles/using-pull-requests<br />
<br />
Now wait for the pull request to be merged into lunar-linux/<repo> or be rejected.<br />
<br />
=== Removing a development branch ===<br />
When you are done with a branch. It was pulled into lunar-linux/<repo> or you discontinued the feature. You want to delete the branch.<br />
To delete a remote branch you need to push the branch with a : in front if it's name.<br />
<br />
git push origin :<branchname><br />
<br />
'''note:''' If a request is successfully pulled github will provide a button at the bottom of the pull request to delete your remove branch.<br />
<br />
After removing a remote branch the local branch still exists. If you are also done with you local branch you can delete it too.<br />
<br />
git branch -d <branchname><br />
<br />
=== What branches do I have? ===<br />
You can see all your remote branches on github. You can also use you local git to list them.<br />
<br />
Show your local branches.<br />
<br />
git branch<br />
<br />
Show your remote branches.<br />
<br />
git branch -r<br />
<br />
=== Reference ===<br />
* https://help.github.com/articles/fork-a-repo<br />
* https://help.github.com/articles/using-pull-requests</div>Cavalierhttp://wiki.lunar-linux.org/Module_GuidelinesModule Guidelines2013-06-09T21:13:25Z<p>Cavalier: /* DEPENDS */</p>
<hr />
<div>__TOC__<br />
<br />
== Generic ==<br />
These guidelines apply to all of a module's files.<br />
* Never use tabs. '''Use spaces''' instead.<br />
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).<br />
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.<br />
<br />
== DETAILS ==<br />
<br />
* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.<br />
**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.<br />
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.<br />
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.<br />
* Avoid using the module's name in the SHORT field.<br />
** e.g. instead of <code>SHORT="MyModule is an application designed to take over the world."</code> you should use <code>SHORT="an application designed to take over the world"</code><br />
** 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.<br />
* 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.<br />
* Make sure to check whether a module is '''PSAFE''' or not. A lot of programs fail to build with parallel makes.<br />
<br />
* If the module is a development version downloaded from a source code management system, rather than a release tarball:<br />
** the module should be in the '''zbeta''' section of the [[moonbase]].<br />
** VERSION should be set to ''beta'', ''cvs'', ''git'', ''svn'', or similar.<br />
** UPDATED should not be a fixed date, but should be generated using '''`date -u +%Y%m01`''' or similar. An explicit '''lin myModule''' will automatically update the source code from the repository, but '''lunar update''' will not trigger another download and rebuild until the generated date changes.<br />
<br />
== DEPENDS ==<br />
* Only list unique dependencies.<br />
** 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."<br />
* Never put logic into this file. The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].<br />
** 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 eert''' and '''lvu leert'''.<br />
* If possible, always provide the means to disable support for an optional dependency, even if that optional module is installed.<br />
** 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.<br />
* Do not use '&&' delimiters to separate multiple [[depends]] and [[optional_depends]] calls.<br />
** Old modules used them to be consistent with [[BUILD]] files, but they are not required. New modules should not use them.<br />
* Use '''lvu links''' to help determine depends.<br />
<br />
== CONFLICTS ==<br />
* Remember to add a CONFLICTS to both modules that conflict with each other.<br />
** Use '''lvu conflicts''' to help determine conflicts.<br />
* 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.<br />
<br />
== CONFIGURE ==<br />
<br />
== PRE_BUILD ==<br />
* Apply patches or '''sedit''' here.<br />
** Create a separate patch file and apply it with '''patch_it'''.<br />
** Set SOURCE2 in DETAILS as if the patch were an additional source file.<br />
** Set SOURCE2_URL to $PATCH_URL<br />
** Copy the patch file to /var/spool/lunar during testing.<br />
** Remember to send it to the mailing list at lunar-dev (at) lunar-linux (dot) org, or include it during '''lvu submit'''.<br />
<br />
== BUILD ==<br />
<br />
* Try to avoid patching source files here. Place these patches in PRE_BUILD.<br />
<br />
* Don't install files after calling '''devoke_installwatch'''.<br />
** Try hard not to require '''devoke_installwatch''' at all. Don't use it, ever.<br />
<br />
* Don't use ( ... ) > $C_FIFO 2>&1.<br />
** This is no longer required and new modules shouldn't use them.<br />
** Remove them when altering a module and remove the corresponding initial indent.<br />
<br />
== POST_BUILD ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== POST_INSTALL ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== PRE_REMOVE ==<br />
<br />
== POST_REMOVE ==</div>Cavalierhttp://wiki.lunar-linux.org/Module_GuidelinesModule Guidelines2013-06-09T21:12:17Z<p>Cavalier: /* CONFLICTS */</p>
<hr />
<div>__TOC__<br />
<br />
== Generic ==<br />
These guidelines apply to all of a module's files.<br />
* Never use tabs. '''Use spaces''' instead.<br />
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).<br />
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.<br />
<br />
== DETAILS ==<br />
<br />
* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.<br />
**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.<br />
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.<br />
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.<br />
* Avoid using the module's name in the SHORT field.<br />
** e.g. instead of <code>SHORT="MyModule is an application designed to take over the world."</code> you should use <code>SHORT="an application designed to take over the world"</code><br />
** 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.<br />
* 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.<br />
* Make sure to check whether a module is '''PSAFE''' or not. A lot of programs fail to build with parallel makes.<br />
<br />
* If the module is a development version downloaded from a source code management system, rather than a release tarball:<br />
** the module should be in the '''zbeta''' section of the [[moonbase]].<br />
** VERSION should be set to ''beta'', ''cvs'', ''git'', ''svn'', or similar.<br />
** UPDATED should not be a fixed date, but should be generated using '''`date -u +%Y%m01`''' or similar. An explicit '''lin myModule''' will automatically update the source code from the repository, but '''lunar update''' will not trigger another download and rebuild until the generated date changes.<br />
<br />
== DEPENDS ==<br />
* Only list unique dependencies.<br />
** 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."<br />
* Never put logic into this file. The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].<br />
** 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 eert''' and '''lvu leert'''.<br />
* If possible, always provide the means to disable support for an optional dependency, even if that optional module is installed.<br />
** 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.<br />
* Do not use '&&' delimiters to separate multiple [[depends]] and [[optional_depends]] calls.<br />
** Old modules used them to be consistent with [[BUILD]] files, but they are not required. New modules should not use them.<br />
<br />
== CONFLICTS ==<br />
* Remember to add a CONFLICTS to both modules that conflict with each other.<br />
** Use '''lvu conflicts''' to help determine conflicts.<br />
* 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.<br />
<br />
== CONFIGURE ==<br />
<br />
== PRE_BUILD ==<br />
* Apply patches or '''sedit''' here.<br />
** Create a separate patch file and apply it with '''patch_it'''.<br />
** Set SOURCE2 in DETAILS as if the patch were an additional source file.<br />
** Set SOURCE2_URL to $PATCH_URL<br />
** Copy the patch file to /var/spool/lunar during testing.<br />
** Remember to send it to the mailing list at lunar-dev (at) lunar-linux (dot) org, or include it during '''lvu submit'''.<br />
<br />
== BUILD ==<br />
<br />
* Try to avoid patching source files here. Place these patches in PRE_BUILD.<br />
<br />
* Don't install files after calling '''devoke_installwatch'''.<br />
** Try hard not to require '''devoke_installwatch''' at all. Don't use it, ever.<br />
<br />
* Don't use ( ... ) > $C_FIFO 2>&1.<br />
** This is no longer required and new modules shouldn't use them.<br />
** Remove them when altering a module and remove the corresponding initial indent.<br />
<br />
== POST_BUILD ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== POST_INSTALL ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== PRE_REMOVE ==<br />
<br />
== POST_REMOVE ==</div>Cavalierhttp://wiki.lunar-linux.org/Module_GuidelinesModule Guidelines2013-06-09T21:10:48Z<p>Cavalier: /* BUILD */</p>
<hr />
<div>__TOC__<br />
<br />
== Generic ==<br />
These guidelines apply to all of a module's files.<br />
* Never use tabs. '''Use spaces''' instead.<br />
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).<br />
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.<br />
<br />
== DETAILS ==<br />
<br />
* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.<br />
**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.<br />
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.<br />
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.<br />
* Avoid using the module's name in the SHORT field.<br />
** e.g. instead of <code>SHORT="MyModule is an application designed to take over the world."</code> you should use <code>SHORT="an application designed to take over the world"</code><br />
** 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.<br />
* 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.<br />
* Make sure to check whether a module is '''PSAFE''' or not. A lot of programs fail to build with parallel makes.<br />
<br />
* If the module is a development version downloaded from a source code management system, rather than a release tarball:<br />
** the module should be in the '''zbeta''' section of the [[moonbase]].<br />
** VERSION should be set to ''beta'', ''cvs'', ''git'', ''svn'', or similar.<br />
** UPDATED should not be a fixed date, but should be generated using '''`date -u +%Y%m01`''' or similar. An explicit '''lin myModule''' will automatically update the source code from the repository, but '''lunar update''' will not trigger another download and rebuild until the generated date changes.<br />
<br />
== DEPENDS ==<br />
* Only list unique dependencies.<br />
** 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."<br />
* Never put logic into this file. The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].<br />
** 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 eert''' and '''lvu leert'''.<br />
* If possible, always provide the means to disable support for an optional dependency, even if that optional module is installed.<br />
** 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.<br />
* Do not use '&&' delimiters to separate multiple [[depends]] and [[optional_depends]] calls.<br />
** Old modules used them to be consistent with [[BUILD]] files, but they are not required. New modules should not use them.<br />
<br />
== CONFLICTS ==<br />
* Remember to add a CONFLICTS to both modules that conflict with each other.<br />
* 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.<br />
<br />
== CONFIGURE ==<br />
<br />
== PRE_BUILD ==<br />
* Apply patches or '''sedit''' here.<br />
** Create a separate patch file and apply it with '''patch_it'''.<br />
** Set SOURCE2 in DETAILS as if the patch were an additional source file.<br />
** Set SOURCE2_URL to $PATCH_URL<br />
** Copy the patch file to /var/spool/lunar during testing.<br />
** Remember to send it to the mailing list at lunar-dev (at) lunar-linux (dot) org, or include it during '''lvu submit'''.<br />
<br />
== BUILD ==<br />
<br />
* Try to avoid patching source files here. Place these patches in PRE_BUILD.<br />
<br />
* Don't install files after calling '''devoke_installwatch'''.<br />
** Try hard not to require '''devoke_installwatch''' at all. Don't use it, ever.<br />
<br />
* Don't use ( ... ) > $C_FIFO 2>&1.<br />
** This is no longer required and new modules shouldn't use them.<br />
** Remove them when altering a module and remove the corresponding initial indent.<br />
<br />
== POST_BUILD ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== POST_INSTALL ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== PRE_REMOVE ==<br />
<br />
== POST_REMOVE ==</div>Cavalierhttp://wiki.lunar-linux.org/Module_BasicsModule Basics2013-06-09T15:26:40Z<p>Cavalier: BUILD: Removed note about ( ... ) > $C_FIFO 2>&1</p>
<hr />
<div>__TOC__<br />
<br />
In ''Lunar'' parlance, software packages are called [[modules]]. The collection of all modules is the [[moonbase]], which is simply a directory (usually <code>/var/lib/lunar/moonbase/</code>) containing ''sections'' (i.e. directories) which in turn contain the [[module]] directories.<br />
<br />
A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in <code>/etc</code>. Some modules require only a [[DETAILS]] file, however this is only the case for a few of the modules in the entire moonbase. In each case, after [[DETAILS]], [[DEPENDS]], and [[CONFIGURE]], where a module can use lunar's default internal function(s), there is no need for a module-specific script.<br />
<br />
* [[DETAILS]] sets version, source URL(s) and other critical data<br />
* [[CONFLICTS]] specifies modules which must (will) be removed by module<br />
* [[CONFIGURE]] interactive script where build options can be set<br />
* [[DEPENDS]] specifies required and optional packages<br />
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal<br />
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs<br />
* [[BUILD]] runs necessary variations on: configure; make; make install<br />
* [[POST_BUILD]] install configuration scripts and data.<br />
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes<br />
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal<br />
<br />
'''Note:''' modules that require changes for 64-bit systems may also have DETAILS.x86_64, etc.<br />
<br />
<br />
== Package Build and Install Scripts ==<br />
<br />
The following scripts are used by [[Tools:lin|lin]] or indirectly by [[lunar]] when building modules.<br />
<br />
<br />
=== The DETAILS script ===<br />
<br />
Every module is required to have at least a [[DETAILS]] file. A minimal [[DETAILS]] may appear as follows: (<code>/var/lib/lunar/moonbase/editors/emacs/DETAILS</code>)<br />
<br />
MODULE=emacs<br />
VERSION=21.3<br />
SOURCE=$MODULE-$VERSION.tar.gz<br />
SOURCE_URL=$GNU_URL/$MODULE<br />
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki><br />
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980<br />
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki><br />
ENTERED=20010922<br />
UPDATED=20020529<br />
SHORT="the extensible, self-documenting real-time display editor"<br />
<br />
cat << EOF<br />
Emacs is the extensible, customizable, self-documenting real-time<br />
display editor. <br />
EOF<br />
<br />
Other SOURCE_URLS in lunar :<br />
* $GNOME_URL : GNOME mirrors<br />
* $GNU_URL : GNU mirrors<br />
* $KDE_URL : KDE mirrors<br />
* $SFORGE_URL : SourceForge mirrors<br />
* $LRESORT_URL : lunar-linux mirrors<br />
* $XFREE86_URL : XFree86 mirrors<br />
* $XORG_URL : x.org packages mirrors<br />
* $KERNEL_URL : kernel, kernel tools mirrors<br />
* $PATCH_URL : the place for *.patch or *.diff files which are not downloadable from other public hosts.<br />
** See [[Module Guidelines]] about creating patches for use in the BUILD file.<br />
** Such patches may be sent unpacked to Lunar developers mailing list: lunar-dev (at) lunar-linux (dot) org so that a Lunar developer can check it, pack it as *.bz2 archive then upload it to $PATCH_URL server.<br />
** Otherwise it may be copied to the module directory to be included as part of the '''lvu submit'''<br />
<br />
The use of _URL mirrors is very important because:<br />
* downloads are faster because mirror is usually very close to user<br />
* if any mirror server fails there is another one on list so user is not left with broken download<br />
* international Internet connections are less blocked<br />
<br />
Other optional fields :<br />
* If the application does not compile on more than one thread, add: PSAFE="no" or PSAFE=no<br />
* If the tarball is not extracting into the default $MODULE-$VERSION (e.g. emacs-21.7), add: SOURCE_DIRECTORY=$BUILD_DIRECTORY/"$MODULE"_"$VERSION"_src<br />
* If you want your name in the module and be listed as maintainer and like to be notified when somebody modifies the module, add : MAINTAINER=youremailadress<br />
* If you have more than one SOURCE_URL, list them as: SOURCE_URL=, SOURCE_URL[1]=, SOURCE_URL[2]=, ...<br />
* If you have more than one SOURCE, list them as: SOURCE ,SOURCE2, SOURCE3, ... (don't forget to tell the BUILD script what to do with it...) and add a SOURCE1_URL as well...<br />
* If you want to force lunar to use the gcc4 compiler for this module, add: LUNAR_COMPILER=GCC_4_0 or GCC_3_4 for gcc3<br />
<br />
Update the UPDATED field only when you have added something that will change the compile behaviour, updated the version or you added configure options... don't change it just for outlining the DETAILS or BUILD or... file, so in general don't force ppl to recompile if all you did what tweaking around a bit...<br />
* Check [[Module_Guidelines]] for special handling of UPDATED for ''*-cvs'' or ''*-svn'' modules in '''zbeta'''.<br />
<br />
The SOURCE_VFY field can be used to check that the downloaded source file has not been corrupted, or changed, since the module was last updated. It should be omitted for modules that download snapshots of sources from svn, cvs, git repositories or similar because the sources could change between downloads.<br />
sha1 checksums are preferred, md5sums can be listed as SOURCE_VFY=md5: <br />
<br />
If you find a MAINTAINER field please respect this and notify the person listed there that you will or have updated his module.<br />
<br />
With comments, default values:<br />
<br />
MODULE=emacs # Module name, yes it's redundant<br />
VERSION=21.3 # Version, changes *often*<br />
SOURCE=$MODULE-$VERSION.tar.gz # Source filename<br />
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks<br />
# ($BUILD_DIRECTORY=/usr/src)<br />
SOURCE_URL[0]=$GNU_URL/$MODULE # Download URL<br />
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki> # Alternate URL(s)<br />
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980 # Sets sha1 hash or pgp/gpg sig url<br />
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more<br />
ENTERED=20010922 # First appearance in moonbase<br />
UPDATED=20020529 # Date of latest change.<br />
# Force update by setting this<br />
<br />
# The remaining lines are used for input to the 'lvu what' command<br />
# and are best copied from the source-maintainer's own description.<br />
<br />
SHORT="the extensible, self-documenting real-time display editor"<br />
<br />
cat << EOF<br />
Emacs is the extensible, customizable, self-documenting real-time<br />
display editor. <br />
EOF<br />
<br />
=== The DEPENDS script ===<br />
<br />
The [[DEPENDS]] script is essential to configuration management, and is the key to the overall operation of lunar. Dependencies should be exactly specified, preferably not assuming the presence of any other modules, while knowing the sub-dependencies of the modules which are added and not adding those explictly where not needed.<br />
<br />
'''Warning''' - Getting this right is difficult. Because the state of installed packages may vary widely, it's important to have a good understanding of what might be or not be installed on a target system.<br />
<br />
'''Note''' - By convention Lunar does not include the X Window System, xfree86 or XOrg, in any dependency. There are two reasons for this choice. First we expect that users must understand that to use a graphical application locally, the X Window System must be installed. Second, due to the sligtly unusual definition of client and server used by X11, it is often in fact possible to build graphical applications and tools for remote display, without the server components locally installed. At some future date we may elect to provide a client-only installation of xfree86.<br />
<br />
[[DEPENDS]] may include both required and optional dependencies. The '''depends()''' function statement simply determines one required package. The optional_depends function is a little more complex. It consists of the required package, necessary --options to give to <code>./configure</code> for yes and no respectively, and an explanatory comment telling the user the purpose of the option being presented. A typical [[DEPENDS]] file might appear as follows: (<code>/var/lib/lunar/moonbase/devel/subversion/DEPENDS</code>)<br />
<br />
depends zlib<br />
depends openssl<br />
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"<br />
# ^ ^ ^ ^<br />
# | | | |<br />
# optional package if "Y" if "N" explanatory comment<br />
# { ./configure strings }<br />
<br />
Many old modules use '&&' in [[DEPENDS]] to be consistent with [[BUILD]] files, but the '&&' delimiter is not required and new [[DEPENDS]] files should not use it.<br />
<br />
* '''Important''' - You may not use '''if module_installed...''' or other general bash programming in the [[DEPENDS]] file to handle conditional dependencies. This is to keep the dependency tracking code in the lunar tools as simple and fast as possible.<br />
<br />
'''Aliases'''<br />
<br />
Aliases are a mean to select a generic module. When you need a functionnality that can be provided by two or more softwares, you can select one of them to provide a correct dependency.<br />
<br />
Example /var/lib/lunar/moonbase/aliases:<br />
<code><br />
%APACHE:apache apache2 apache-mod_ssl<br />
%FAM:fam gamin<br />
%GECKO_RENDERER: firefox thunderbird mozilla<br />
%GHOSTSCRIPT:espgs ghostscript<br />
%MTA:postfix exim sendmail esmtp<br />
%SLANG:slang slang2<br />
%X:XOrg XOrg-test xfree86 xfree86-beta<br />
%XMLRENDERER: libxml2 expat<br />
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde<br />
</code><br />
<br />
For example you can choose %X instead of XOrg in a module that would depends on any X server:<br />
<code><br />
depends %X<br />
</code><br />
<br />
=== The CONFLICTS script ===<br />
<br />
This script is simply used to specify modules which will be removed when a given module is installed. An example would be: (<code>/var/lib/lunar/moonbase/editors/elvis/CONFLICTS</code>)<br />
<br />
conflicts vim<br />
<br />
<br />
=== The CONFIGURE script ===<br />
<br />
The [[CONFIGURE]] script is used to collect interactive input from the user on optional parameters for the software build. use the '''query''' function and provide a default answer to each question. The results of the answers are then used to store configuration variables needed in configuration state files. An a simple example might be: (<code>/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE</code>)<br />
<br />
if ! grep -q CONFIGURED $MODULE_CONFIG ; then<br />
if query "Enable experimental external HKP keyserver interface? " n ; then<br />
OPTS="$OPTS --enable-external-hkp"<br />
fi<br />
echo 'CONFIGURED="y"' >> $MODULE_CONFIG<br />
echo 'OPTS='\"$OPTS\" >> $MODULE_CONFIG<br />
fi<br />
<br />
Another way is using '''mquery''' like the lilo module does:<br />
<br />
mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y<br />
<br />
mquery ENABLE_FOO "Enable foo?" n "--enable-foo --enable-foo2" "--disable-foo --disable-foo2"<br />
<br />
Where "No" would be the default answer for the user. When he chooses to enable-foo, then answer "yes" would be stored in the ENABLE_FOO variable and --enable-foo and --enable-foo2 will get added to the ./configure command in the BUILD script.<br />
<br />
=== The PRE_BUILD script ===<br />
<br />
[[PRE_BUILD]] is used where special processing is needed before undertaking the actual build steps. Typical requirements include unpacking multiple sources, creating necessary system or source-tree direcotries and applying source patches. And example would be: (<code>/var/lib/lunar/moonbase/doc-tools/html2db/PRE_BUILD</code>)<br />
<br />
mk_source_dir $SOURCE_DIRECTORY &&<br />
unpack $SOURCE &&<br />
cd $MODULE<br />
unpack $SOURCE2<br />
cd tidy<br />
patch_it $SOURCE_CACHE/$SOURCE3 0<br />
cd /usr/src/$MODULE<br />
<br />
<br />
=== The BUILD script ===<br />
<br />
[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:<br />
<br />
Function '''default_build()''' calls '''default_config''' which executes:<br />
<br />
./configure --build=$BUILD \<br />
--prefix=/usr \<br />
--sysconfdir=/etc \<br />
--localstatedir=/var \<br />
--infodir=/usr/share/info \<br />
--mandir=/usr/share/man \<br />
$OPTS<br />
<br />
Next, '''default_build()''' calls '''default_make''' which executes:<br />
<br />
make &&<br />
prepare_install &&<br />
make install<br />
<br />
The '''prepare_install''' should only be called immediately before the '''make install''' phase, so that the package management system only tracks the installed files and not any intermediate build files.<br />
<br />
2011-02-20: Be aware that several modules in the moonbase appear to get this wrong, so take care!<br />
<br />
If you have modules from git,svn or cvs, the ''configure'' script is missing most of the time. You can then use the ''default_cvs_build()'' function. The commands run are:<br />
<br />
./autogen.sh --prefix=/usr <br />
<br />
it will then call ''default_make()'' <br />
<br />
Where this build configuration does not work, the [[BUILD]] script is used to provide the needed steps. About 75% of modules need a [[BUILD]] script. Two examples include: (<code>/var/lib/lunar/moonbase/archive/gzip/BUILD</code>)<br />
<br />
./configure --build=$BUILD \<br />
--prefix=/usr \<br />
--bindir=/bin \<br />
--infodir=/usr/share/info \<br />
--mandir=/usr/share/man &&<br />
make &&<br />
prepare_install &&<br />
make bindir=/bin install<br />
<br />
and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)<br />
<br />
cd $SOURCE_DIRECTORY &&<br />
sedit 's/usr.local/usr/' Makefile &&<br />
sedit 's/= man/= share\/man/' Makefile &&<br />
sedit 's/ucb/bin/' Makefile &&<br />
sedit 's/= termlib/= ncurses/' Makefile &&<br />
make &&<br />
prepare_install &&<br />
make install<br />
<br />
The first example is a build which needs non-standard 'configure' and 'make install' commands. The second is a build which does not use gnu auto-tools' 'configure' script.<br />
<br />
In the examples above, the [[BUILD]] scripts contain multiple commands separated by '&&' to ensure that execution stops as soon as any command fails. The '&&' are 'and' operations: the command after the '&&' will only be run if the one before the '&&' completed successfully. The use of '&&' is '''required''' in multi-command [[BUILD]] scripts.<br />
<br />
=== The POST_BUILD script ===<br />
<br />
[[POST_BUILD]] runs in place of the '''default_post_build''' routine which is used to install minor documentation and transfer/enable initialization scripts and similar system data, mostly into <code>/etc</code>. <br />
<br />
[[POST_BUILD]] script usage is '''deprecated'''. You should install your config files in [[BUILD]] (remember not to overwrite previous config files!) or install defaults from [[POST_INSTALL]] (again, do not overwrite present files!). The ability to use a [[POST_BUILD]] script is purely for certain internal functions.<br />
<br />
=== The POST_INSTALL script ===<br />
<br />
[[POST_INSTALL]] has no equivalent functions, and is run to handle post-installation work in a general manner. An example is: (<code>/var/lib/lunar/moonbase/compilers/gcc/POST_INSTALL</code>)<br />
<br />
cd /usr/lib/gcc-lib/$BUILD/$VERSION &&<br />
ln -sf /usr/bin/cpp cpp &&<br />
cd /lib/ &&<br />
ln -sf /usr/bin/cpp cpp && <br />
if [ ! -e /usr/bin/cc ] ; then<br />
ln -s gcc /usr/bin/cc<br />
fi<br />
<br />
As in the [[BUILD]] scripts, the '&&' represent 'and' operations, but their use in [[POST_INSTALL]] scripts is '''preferred''' rather than '''required'''.<br />
<br />
== Package Removal Scripts ==<br />
<br />
Module removal is handled by [[lrm]]. Because installation is monitored and backup tarballs are created using installwatch, most of package removal is handled automatically using the logs created by installwatch. However we provide for additional actions to be taken through the [[PRE_REMOVE]] and [[POST_REMOVE]] scripts.<br />
<br />
<br />
=== The PRE_REMOVE script ===<br />
<br />
[[PRE_REMOVE]] is needed to execute any tasks needed prior to the main task of removing all files installed by the module. An example would be: (<code>/var/lib/lunar/moonbase/mail/docbook-3.1/PRE_REMOVE</code>)<br />
<br />
CENTRALIZED=/etc/sgml/catalog<br />
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION<br />
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog<br />
<br />
<br />
=== The POST_REMOVE Script ===<br />
<br />
[[POST_REMOVE]] may be used to remove data not tracked by installwatch and to correctly adjust remaining configuration files and data. Examples would include: (<code>/var/lib/lunar/moonbase/devel/binutils/POST_REMOVE</code>)<br />
<br />
install-info --delete as --info-dir /usr/info<br />
install-info --delete bfd --info-dir /usr/info<br />
install-info --delete binutils --info-dir /usr/info<br />
install-info --delete configure --info-dir /usr/info<br />
install-info --delete gasp --info-dir /usr/info<br />
install-info --delete gprof --info-dir /usr/info<br />
install-info --delete ld --info-dir /usr/info<br />
<br />
or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)<br />
<br />
if module_installed apache; then<br />
cp /etc/httpd/httpd.conf /tmp/httpd.conf<br />
grep -v "LoadModule php4_module" /tmp/httpd.conf |<br />
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf<br />
rm -f /tmp/httpd.conf<br />
elif module_installed apache_mod_ssl; then<br />
cp /etc/httpsd/httpd.conf /tmp/httpd.conf<br />
grep -v "LoadModule php4_module" /tmp/httpd.conf |<br />
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf<br />
rm -f /tmp/httpd.conf<br />
fi</div>Cavalierhttp://wiki.lunar-linux.org/Module_GuidelinesModule Guidelines2013-06-09T14:54:43Z<p>Cavalier: PRE_BUILD and BUILD description</p>
<hr />
<div>__TOC__<br />
<br />
== Generic ==<br />
These guidelines apply to all of a module's files.<br />
* Never use tabs. '''Use spaces''' instead.<br />
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).<br />
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.<br />
<br />
== DETAILS ==<br />
<br />
* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.<br />
**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.<br />
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.<br />
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.<br />
* Avoid using the module's name in the SHORT field.<br />
** e.g. instead of <code>SHORT="MyModule is an application designed to take over the world."</code> you should use <code>SHORT="an application designed to take over the world"</code><br />
** 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.<br />
* 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.<br />
* Make sure to check whether a module is '''PSAFE''' or not. A lot of programs fail to build with parallel makes.<br />
<br />
* If the module is a development version downloaded from a source code management system, rather than a release tarball:<br />
** the module should be in the '''zbeta''' section of the [[moonbase]].<br />
** VERSION should be set to ''beta'', ''cvs'', ''git'', ''svn'', or similar.<br />
** UPDATED should not be a fixed date, but should be generated using '''`date -u +%Y%m01`''' or similar. An explicit '''lin myModule''' will automatically update the source code from the repository, but '''lunar update''' will not trigger another download and rebuild until the generated date changes.<br />
<br />
== DEPENDS ==<br />
* Only list unique dependencies.<br />
** 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."<br />
* Never put logic into this file. The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].<br />
** 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 eert''' and '''lvu leert'''.<br />
* If possible, always provide the means to disable support for an optional dependency, even if that optional module is installed.<br />
** 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.<br />
* Do not use '&&' delimiters to separate multiple [[depends]] and [[optional_depends]] calls.<br />
** Old modules used them to be consistent with [[BUILD]] files, but they are not required. New modules should not use them.<br />
<br />
== CONFLICTS ==<br />
* Remember to add a CONFLICTS to both modules that conflict with each other.<br />
* 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.<br />
<br />
== CONFIGURE ==<br />
<br />
== PRE_BUILD ==<br />
* Apply patches or '''sedit''' here.<br />
** Create a separate patch file and apply it with '''patch_it'''.<br />
** Set SOURCE2 in DETAILS as if the patch were an additional source file.<br />
** Set SOURCE2_URL to $PATCH_URL<br />
** Copy the patch file to /var/spool/lunar during testing.<br />
** Remember to send it to the mailing list at lunar-dev (at) lunar-linux (dot) org, or include it during '''lvu submit'''.<br />
<br />
== BUILD ==<br />
<br />
* Try to avoid patching source files here. Place these patches in PRE_BUILD.<br />
<br />
* Don't install files after calling '''devoke_installwatch'''.<br />
<br />
* Don't use ( ... ) > $C_FIFO 2>&1.<br />
** This is no longer required and new modules shouldn't use them.<br />
** Remove them when altering a module and remove the corresponding initial indent.<br />
<br />
== POST_BUILD ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== POST_INSTALL ==<br />
<br />
* Don't install any files into the system.<br />
<br />
== PRE_REMOVE ==<br />
<br />
== POST_REMOVE ==</div>Cavalier