MOONBASE(5) LUNAR MOONBASE(5) NAME moonbase - the software catalog for the Lunar-Linux distribution COPYRIGHT moonbase(5) is Copyright (C) 2002-2003 Terry Chan with portions copyrighted by previous authors 2001-2002 DESCRIPTION The software catalog is a list of software modules (simply referred to as "modules") divided into sections. Each module contains one or more descrip- tion files. Description files contain such information as module name, ver- sion, URL, directory information, etc. Other description files provide un- packing, compilation, installation, and tracking instructions. One section in the software catalog of particular interest is PROFILES. Profiles are groups of modules. With profiles you can automatically install predefined or custom-built module sets using a single command. SUMMARY The moonbase is found under /var/lib/lunar. The top level of directories are the section names. The directories under the section names are the mod- ules. Each module directory will have a BASH description file called DE- TAILS and optionally contain one or more of the following description files: CONFIGURE, DEPENDS, CONFLICTS, CATALYST, PRE_BUILD, BUILD, POST_BUILD, POST_INSTALL, POST_REMOVE. If a description file does not ex- ist in the module directory then a set of default description instructions are used. The default instructions for each description file can be found in /var/lib/lunar/functions/*.lunar. DETAILS PROFILES Each profile contains a simplified DETAILS file: profile name, version, and description. Profiles are effectively just a DEPEND file with a list of modules to be installed. DESCRIPTION FILES A typical source code installation might look like this (assume the appli- cation is called foo): step 1) find the URL and download the tarball step 2) tar xvfz foo-1.00.tar.gz step 3) cd foo step 4) less README (perhaps you skip this step?) step 5) less INSTALL (... and this one?) step 6) ./configure step 7) make step 8) make install Here is a breakdown of the description files and how they relate to the above installation procedure: DETAILS This file is required and describes the URL for step 1. It also con- tains version information, module name, source name, source direc- tory, and a description of the module. CONFIGURE The configure script. DEPENDS This file contains a list of other modules upon which the module de- pends. If dependencies are turned on then the modules listed are installed in order prior to installing module. The following functions are available in DEPENDS files: depends module [on_opts] [off_opts] Declares a required dependency. The module will always be in- stalled before the current module. Configure options on_opts are passed when the dependency is present. optional_depends module on_opts off_opts description [default] Declares an optional dependency. The user is prompted whether to enable it. If the module is already installed, the de- fault is "y"; otherwise "n". The default parameter can over- ride this ("y" or "n"). optional_depends_requires leader follower1 [follower2 ...] Declares follower dependencies that are automatically ac- cepted or rejected based on the user's decision for leader. If the leader was accepted ("on"), all followers are also ac- cepted. If the leader was rejected ("off"), all followers are also rejected. This must be placed after the leader's op- tional_depends call. Useful for plugin libraries that only make sense when the parent library is enabled (e.g., SDL_ttf and SDL_image when SDL is accepted). optional_depends_one_of "description" [@]mod1 on1 off1 [[@]mod2 on2 off2 ...] Presents a mutually exclusive choice of optional dependen- cies. The user is prompted for each module in order; if the module is already installed, the default is "y", otherwise "n". Once one is accepted, the rest are automatically re- jected. On re-runs, existing choices are honored without re- prompting. Arguments are specified as triplets of module, on_opts, off_opts. The description is shown as a header (e.g., "SSL provider"). A leading @ on a module name marks it as the preferred de- fault for unattended selection. When present, PROMPT_DELAY will accept the @-marked member and reject the rest, regard- less of which modules are already installed. Without any marker the existing install-state behavior applies. At most one marker is honored per call; if multiple are specified, the first wins. Cyclic Dependencies When two modules have a circular dependency (e.g., module A depends on B, required or optional, and B depends on A), the dependency re- solver detects the cycle automatically. Required cyclic dependencies are auto-accepted as "on"; optional cyclic dependencies are also auto-accepted as "on". An informational message is displayed in both cases. The first module in the cycle is built without the second, then the second is built. To trigger a rebuild of the first module with full support after the second is installed, module authors can provide a CATALYST file. The catalyst system supports enable and disable actions that fire when a watched module is installed or removed. For example, if module vigra requires openexr to be built with a specific feature enabled, vi- gra's CATALYST file can watch openexr and trigger a rebuild of vigra when openexr is installed, ensuring the feature is available. This pattern is useful when the dependency is not just "present or ab- sent" but requires specific build-time configuration in the depen- dency. CONFLICTS Contains a list of modules that conflict with this module. Use spar- ingly. A good example of a reasonable use is when you have two mod- ules in the moonbase that are the same but one is patched. eg apache and apache-mod_ssl CATALYST Optional file that declares reactive triggers. When a watched module is installed or removed, the system automatically performs an action on the module that owns the CATALYST file (the "reactor"). Each line has the format: event watched_module action [param] [immediate] Events: on_install, on_pre_install, on_remove, on_pre_remove Actions: lin (rebuild the reactor), lrm (remove the reactor), fix (run integrity checks and repair), enable (turn on an optional de- pendency), disable (turn off an optional dependency), exec (run a custom script from the module directory) The enable and disable actions take a dependency module name as param. The exec action takes a script filename as param; the script is sourced with CATALYST_MODULE and CATALYST_MODULE_VERSION set to the watched module that caused the trigger. The optional immediate keyword causes the trigger to fire right af- ter the watched module completes instead of being collected for batch firing after all modules complete. This is important for crit- ical chains where a later module depends on the triggered rebuild (e.g. openssl triggering a wget rebuild). Pre-event triggers (on_pre_install, on_pre_remove) always fire imme- diately regardless of the immediate keyword. Lines beginning with # are comments. The trigger cache is stored in /var/state/lunar/catalyst.cache and is rebuilt automatically when moonbase is updated. PRE_BUILD This describes the unpacking process as performed in step 2. The de- fault PRE_BUILD will work for tarballs with gzip or bzip2 compres- sion. BUILD This describes the compilation and installation processes as per- formed in steps 6-8. If the software module compiles and installs using these 3 steps then the default BUILD can be used. POST_BUILD The default POST_BUILD simply calls the software tracking script. POST_INSTALL There is no default POST_INSTALL. If no POST_INSTALL is present in the module directory then no operations are performed in this step. Normally used to start daemons or extra cleanup or install default configuration files, after the module is ready to execute. POST_REMOVE This is called, if present, after removing the module. See lrm(8). NOTES The best way to learn the software catalog is to examine some of the de- scription files yourself. Most software catalog entries are simple. For ex- ample try looking under /var/lib/lunar/moonbase/editors/emacs. If however you want to look at a very unusual, but much more complex example look at /var/lib/lunar/moonbase/xorg7. To understand how the software catalog works, it is also important to look at /var/lib/lunar/functions/*.lunar and examine the functions default_pre_build, default_build, and de- fault_post_build. AUTHOR Kyle Sallee Updated Thomas Stewart 01/15/2002 Converted to Lunar by Terry Chan 03/23/2002 Updated by Terry Chan 5/22/2002 Updated by Terry Chan 8/08/2003 Updated by Stefan Wold 6/07/2009 Updated by Stefan Wold 02/19/2026 REPORTING BUGS Report bugs to SEE ALSO lunar(8), lin(8), lrm(8), lvu(1), lget(8) WARRANTY This is free software with ABSOLUTELY NO WARRANTY Lunar Linux June 2009 MOONBASE(5)