Lunar Linux - User contributions [en]

Install XOrg7

2006-09-30T17:25:57Z

V3rt1g0: /* Upgrading from XOrg 6.x */

=The path to XOrg7=

==Upgrading from XOrg 6.x==

Currently, the XOrg7 module needs you to do a few things manually if you upgrade from an earlier XOrg 6.x installation. You have to adhere to the following steps. If you do not listen to our advice then you're on your own.

*Remove the old XOrg (XOrg 6.x conflicts with XOrg 7.x)
: <code>lrm XOrg</code>
:: This action will most likely cause some font related modules to recompile, this is to be expected.

*Backup the old /etc/X11 (with your old xorg.conf)
: <code>mv /etc/X11 /etc/X11.old</code>

*Remove the old XOrg installation remains
: <code>rm -fr /usr/X11R6</code>

*Remove some old symlinks if they still exist
**<code>rm /usr/X11</code>
**<code>rm /usr/include/X11</code>
**<code>rm /usr/lib/X11</code>
**<code>rm /usr/include/GL</code>

==Installing XOrg 7.x ==
===Installing xorg-7.0===
As of 2006-06-19 XOrg7 was added to zbeta of moonbase... This means you can just lin XOrg7 to install xorg-7.0

===Installing xorg-7.1===

If you want to install xorg-7.1 you will need the fetch some modules from the development tree of moonbase: 
Fetch the [http://merlin.ugent.be/lunar/xorg7.1.tar.gz XOrg 7.1 tarball] from http://merlin.ugent.be/lunar/ for a snapshot of the experimental moonbase branch and copy the extracted files to your $MOONBASE/zlocal. The tarballs are updated at least once a day .. so you get all the latest changes.

Now you're all set for XOrg 7.1. You may now use the 'XOrg7' module to install XOrg 7.1: 
<code>lin XOrg7</code>

XOrg-7.1 is needed if you want to mess with Xgl.

==Installation notes==

XOrg7 is installing to /usr by default and ''NOT'' to /usr/X11R7 or any other prefix inside /usr. The [http://www.pathname.com/fhs Filesystem Hierarchy Standard] does not allow that. All major linux distributions are following the FHS and have adjusted their builds accordingly:

*[http://lists.debian.org/debian-devel-announce/2006/04/msg00010.html Debian]
*[http://wiki.archlinux.org/index.php/Xorg7 Arch Linux]
*[http://gentoo-wiki.com/HOWTO_Modular_Xorg Gentoo]

You may however set an arbitary prefix for XOrg incase you do not want it to install to /usr. You may do so by running the following command: 
: <code>lunar set X11R7_PREFIX=/your/prefix/here</code> 
The most commonly used prefix would be /usr/X11R7, however, some other prefix inside /opt is entirely possible.

The XOrg7 profile is going to create some symlinks on your system: 
: <code>/usr/X11 -> $MODULE_PREFIX; /usr by default </code>
: <code>/usr/X11R6 -> $MODULE_PREFIX; /usr by default</code> 
The X11R6 symlink is there for compatibility reasons. Many of the older and even some of the newer packages inside the moonbase have a hardcoded path pointing to /usr/X11R6 inside their source trees. Keeping the symlink prevents them from breaking apart.

==Missing modules from the XOrg 7.x modular tree==

Despite our best efforts to give you the whole XOrg 7.x modular tree as modules to install there are still many of them left untouched either because they are not important to run a full featured X environment or nobody had the time to add them yet. As always contribution are welcome and appreciated:

*x11-apps
**appres - list X application resource database
**lbxproxy - Low BandWidth X proxy
**luit - Convert terminal i/o from legacy encodings to UTF-8
**mkcfm - create summaries of CID font metric files
**oclock - round X clock
**proxymngr - proxy manager service
**scripts - run X command on another system via rsh
**sessreg - Register X sessions in system utmp/utmpx databases
**showfont - show information about X font from font server
**twm - simple window manager
**viewres - graphical class/resource browser for Xt
**xbiff - watch mailboxes for new message delivery
**xclipboard - X clipboard manager
**xdbedizzy - DBE sample
**xditview - display ditroff output
**xdm - list X application resource database
**xf86dga - known unto god
**xfd - display all the characters in an X font
**xfindproxy - locate proxy services
**xfontsel - point and click selection of X11 font names
**xfsinfo - X font server information utility
**xfwp - X Firewall Proxy
**xgc - X graphics demo
**xload - system load average display for X
**xlogo - Draw [old] X logo
**xlsclients - list client applications running on a display
**xmag - magnify parts of the screen
**xphelloworld - Xprint sample applications
**xprehashprinterlist - Rehash list of Xprint printers
**xrx - "Broadway"
**xsetmode - set the mode for an X Input device
**xsetpointer - set an X Input device as the main pointer
**xsm - X Session Manager
**xstdcmap - X standard colormap utility
**xvidtune - video mode tuner for Xorg
*x11-data ==> COMPLETE
*x11-doc
**xorg-docs
**xorg-sgml-doctools
*x11-driver
**xf86-video-sunbw2
**xf86-video-suncg3
**xf86-video-suncg6
**xf86-video-suncg14
**xf86-video-sunffb
**xf86-video-sunleo
**xf86-video-suntcx
**xf86-video-tdfx
**xf86-video-tga
**xf86-video-trident
**xf86-video-tseng
*x11-extras ==> COMPLETE
*x11-font
**font-cronyx-cyrillic
**font-daewoo-misc
**font-dec-misc
**font-ibm-type1
**font-isas-misc
**font-jis-misc
**font-micro-misc
**font-misc-cyrillic
**font-misc-ethiopic
**font-misc-meltho
**font-mutt-misc
**font-schumacher-misc
**font-screen-cyrillic
**font-winitzki-cyrillic
*x11-lib
**libAppleWM - platform specific libraries: [MacOS]
**libWindowsWM - platform specific libraries: [Win32]
*x11-proto
**windowswmproto - platform specific protocol headers [Win32]
*x11-util
**lndir
*xserver ==> COMPLETE

Install XOrg7

2006-09-30T17:22:27Z

V3rt1g0: /* Upgrading from XOrg 6.x */

=The path to XOrg7=

==Upgrading from XOrg 6.x==

Currently, the XOrg7 module needs you to do a few things manually if you upgrade from an earlier XOrg 6.x installation. You have to adhere to the following steps. If you do not listen to our advice then you're on your own.

*Remove the old XOrg (XOrg 6.x conflicts with XOrg 7.x)
: <code>lrm XOrg</code>
:: This action will most likely cause some font related modules to recompile, this is to be expected.

*Backup the old /etc/X11 (with your old xorg.conf)
: <code>mv /etc/X11 /etc/X11.old</code>

*Remove the old XOrg installation remains
: <code>rm -fr /usr/X11R6</code>

*Remove some old symlinks
**<code>rm /usr/X11</code>
**<code>rm /usr/include/X11</code>
**<code>rm /usr/lib/X11</code>
**<code>rm /usr/include/GL</code>

==Installing XOrg 7.x ==
===Installing xorg-7.0===
As of 2006-06-19 XOrg7 was added to zbeta of moonbase... This means you can just lin XOrg7 to install xorg-7.0

===Installing xorg-7.1===

If you want to install xorg-7.1 you will need the fetch some modules from the development tree of moonbase: 
Fetch the [http://merlin.ugent.be/lunar/xorg7.1.tar.gz XOrg 7.1 tarball] from http://merlin.ugent.be/lunar/ for a snapshot of the experimental moonbase branch and copy the extracted files to your $MOONBASE/zlocal. The tarballs are updated at least once a day .. so you get all the latest changes.

Now you're all set for XOrg 7.1. You may now use the 'XOrg7' module to install XOrg 7.1: 
<code>lin XOrg7</code>

XOrg-7.1 is needed if you want to mess with Xgl.

==Installation notes==

XOrg7 is installing to /usr by default and ''NOT'' to /usr/X11R7 or any other prefix inside /usr. The [http://www.pathname.com/fhs Filesystem Hierarchy Standard] does not allow that. All major linux distributions are following the FHS and have adjusted their builds accordingly:

*[http://lists.debian.org/debian-devel-announce/2006/04/msg00010.html Debian]
*[http://wiki.archlinux.org/index.php/Xorg7 Arch Linux]
*[http://gentoo-wiki.com/HOWTO_Modular_Xorg Gentoo]

You may however set an arbitary prefix for XOrg incase you do not want it to install to /usr. You may do so by running the following command: 
: <code>lunar set X11R7_PREFIX=/your/prefix/here</code> 
The most commonly used prefix would be /usr/X11R7, however, some other prefix inside /opt is entirely possible.

The XOrg7 profile is going to create some symlinks on your system: 
: <code>/usr/X11 -> $MODULE_PREFIX; /usr by default </code>
: <code>/usr/X11R6 -> $MODULE_PREFIX; /usr by default</code> 
The X11R6 symlink is there for compatibility reasons. Many of the older and even some of the newer packages inside the moonbase have a hardcoded path pointing to /usr/X11R6 inside their source trees. Keeping the symlink prevents them from breaking apart.

==Missing modules from the XOrg 7.x modular tree==

Despite our best efforts to give you the whole XOrg 7.x modular tree as modules to install there are still many of them left untouched either because they are not important to run a full featured X environment or nobody had the time to add them yet. As always contribution are welcome and appreciated:

*x11-apps
**appres - list X application resource database
**lbxproxy - Low BandWidth X proxy
**luit - Convert terminal i/o from legacy encodings to UTF-8
**mkcfm - create summaries of CID font metric files
**oclock - round X clock
**proxymngr - proxy manager service
**scripts - run X command on another system via rsh
**sessreg - Register X sessions in system utmp/utmpx databases
**showfont - show information about X font from font server
**twm - simple window manager
**viewres - graphical class/resource browser for Xt
**xbiff - watch mailboxes for new message delivery
**xclipboard - X clipboard manager
**xdbedizzy - DBE sample
**xditview - display ditroff output
**xdm - list X application resource database
**xf86dga - known unto god
**xfd - display all the characters in an X font
**xfindproxy - locate proxy services
**xfontsel - point and click selection of X11 font names
**xfsinfo - X font server information utility
**xfwp - X Firewall Proxy
**xgc - X graphics demo
**xload - system load average display for X
**xlogo - Draw [old] X logo
**xlsclients - list client applications running on a display
**xmag - magnify parts of the screen
**xphelloworld - Xprint sample applications
**xprehashprinterlist - Rehash list of Xprint printers
**xrx - "Broadway"
**xsetmode - set the mode for an X Input device
**xsetpointer - set an X Input device as the main pointer
**xsm - X Session Manager
**xstdcmap - X standard colormap utility
**xvidtune - video mode tuner for Xorg
*x11-data ==> COMPLETE
*x11-doc
**xorg-docs
**xorg-sgml-doctools
*x11-driver
**xf86-video-sunbw2
**xf86-video-suncg3
**xf86-video-suncg6
**xf86-video-suncg14
**xf86-video-sunffb
**xf86-video-sunleo
**xf86-video-suntcx
**xf86-video-tdfx
**xf86-video-tga
**xf86-video-trident
**xf86-video-tseng
*x11-extras ==> COMPLETE
*x11-font
**font-cronyx-cyrillic
**font-daewoo-misc
**font-dec-misc
**font-ibm-type1
**font-isas-misc
**font-jis-misc
**font-micro-misc
**font-misc-cyrillic
**font-misc-ethiopic
**font-misc-meltho
**font-mutt-misc
**font-schumacher-misc
**font-screen-cyrillic
**font-winitzki-cyrillic
*x11-lib
**libAppleWM - platform specific libraries: [MacOS]
**libWindowsWM - platform specific libraries: [Win32]
*x11-proto
**windowswmproto - platform specific protocol headers [Win32]
*x11-util
**lndir
*xserver ==> COMPLETE

Module Basics

2006-08-28T20:58:51Z

V3rt1g0: tweaks

__TOC__

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.

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.

* [[DETAILS]] sets version, source URL(s) and other critical data
* [[CONFLICTS]] specifies modules which must (will) be removed by module
* [[CONFIGURE]] interactive script where build options can be set
* [[DEPENDS]] specifies required and optional packages
* [[PRE_REMOVE]] used by [[lrm]]; actions which must preceed removal
* [[PRE_BUILD]] most often used for patching, unpacking addional source tarballs
* [[BUILD]] runs necessary variations on: configure; make; make install
* [[POST_BUILD]] install configuration scripts and data.
* [[POST_INSTALL]] messages, notes more cleanups, configuration fixes
* [[POST_REMOVE]] used by [[lrm]]; actions which must follow removal

== Package Build and Install Scripts ==

The following scripts are used by [[lin]] or indirectly by [[lunar]] when building modules.

=== The DETAILS script ===

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

MODULE=emacs
VERSION=21.3
SOURCE=$MODULE-$VERSION.tar.gz
SOURCE_URL=$GNU_URL/$MODULE
SOURCE_URL=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki>
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki>
ENTERED=20010922
UPDATED=20020529
SHORT="the extensible, self-documenting real-time display editor"

cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

Other SOURCE_URLS in lunar :
* $GNOME_URL : GNOME mirrors
* $GNU_URL : GNU mirrors
* $KDE_URL : KDE mirrors
* $SFORGE_URL : SourceForge mirrors
* $LRESORT_URL : lunar-linux mirrors
* $XFREE86_URL : XFree86 mirrors

Other optional fields :
* If the application does not compile on more than one thread, add: PSAFE="no" or PSAFE=no
* If the tarball is not extracting into the default $MODULE-$VERSION (e.g. emacs-21.7), add: SOURCE_DIRECTORY=$BUILD_DIRECTORY/"$MODULE"_"$VERSION"_src
* 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
* If you have more than one SOURCE_URL, list them as: SOURCE_URL=, SOURCE_URL[1]=, SOURCE_URL[2]=, ...
* 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...
* 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

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

sha1 checksums are preferred, md5sums can be listed as SOURCE_VFY=md5:

If you find a MAINTAINER field please respect this and notify the person listed there that you will or have updated his module.

With comments, default values:

MODULE=emacs # Module name, yes it's redundant
VERSION=21.3 # Version, changes *often*
SOURCE=$MODULE-$VERSION.tar.gz # Source filename
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$MODULE-$VERSION # Where source unpacks
# ($BUILD_DIRECTORY=/usr/src)
SOURCE_URL[0]=$GNU_URL/$MODULE # Download URL
SOURCE_URL[1]=<nowiki>ftp://ftp.gnu.org/pub/gnu/$MODULE</nowiki> # Alternate URL(s)
SOURCE_VFY=sha1:94d7ae9cb3aef05159cfff148265fc9ce0973980 # Sets sha1 hash or pgp/gpg sig url
WEB_SITE=<nowiki>http://www.gnu.org/software/emacs</nowiki> # where to learn more
ENTERED=20010922 # First appearance in moonbase
UPDATED=20020529 # Date of latest change.
# Force update by setting this

# The remaining lines are used for input to the 'lvu what' command
# and are best copied from the source-maintainer's own description.

SHORT="the extensible, self-documenting real-time display editor"

cat << EOF
Emacs is the extensible, customizable, self-documenting real-time
display editor.
EOF

=== The DEPENDS script ===

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.

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

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

[[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>)

depends zlib &&
depends openssl &&
optional_depends "db4" "--with-berkeley-db" "" "for creating local repositories"
# ^ ^ ^ ^
# | | | |
# optional package if "Y" if "N" explanatory comment
# { ./configure strings }

the && is not obligatory but makes the file much more readable

'''Aliases'''

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.

Example /var/lib/lunar/moonbase/aliases:
<code>
%APACHE:apache apache2 apache-mod_ssl
%FAM:fam gamin
%GECKO_RENDERER: firefox thunderbird mozilla
%GHOSTSCRIPT:espgs ghostscript
%MTA:postfix exim sendmail esmtp
%SLANG:slang slang2
%X:XOrg XOrg-test xfree86 xfree86-beta
%XMLRENDERER: libxml2 expat
%XSCREENSAVER:xscreensaver xscreensaver-gtk1 xscreensaver-kde
</code>

For example you can choose %X instead of XOrg in a module that would depends on any X server:
<code>
depends %X
</code>

=== The CONFLICTS script ===

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

conflicts vim

=== The CONFIGURE script ===

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

if ! grep -q CONFIGURED $MODULE_CONFIG ; then
if query "Enable experimental external HKP keyserver interface? " n ; then
OPTS="$OPTS --enable-external-hkp"
fi
echo 'CONFIGURED="y"' >> $MODULE_CONFIG
fi

Another way is using '''mquery''' like the lilo module does:

mquery RUN_LILO "Run LILO automatically upon LILO upgrades?" y

=== The PRE_BUILD script ===

[[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>)

mk_source_dir $SOURCE_DIRECTORY &&
unpack $SOURCE &&
cd $MODULE
unpack $SOURCE2
cd tidy
patch_it $SOURCE_CACHE/$SOURCE3 0
cd /usr/src/$MODULE

=== The BUILD script ===

[[BUILD]] is used where the '''default_build()''' function does not work for a given software package. For reference the commands run by default are:

Function '''default_build()''' calls '''default_config''' which executes:

./configure --build=$BUILD \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--infodir=/usr/share/info \
--mandir=/usr/share/man \
$OPTS

Next, '''default_build()''' calls '''default_make''' which executes:

make &&
prepare_install &&
make install

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

(
./configure --build=$BUILD \
--prefix=/usr \
--bindir=/bin \
--infodir=/usr/share/info \
--mandir=/usr/share/man &&
make &&
prepare_install &&
make bindir=/bin install
) > $C_FIFO 2>&1

and: (<code>/var/lib/lunar/moonbase/editors/ex/BUILD</code>)

(
cd $SOURCE_DIRECTORY &&
sedit 's/usr.local/usr/' Makefile &&
sedit 's/= man/= share\/man/' Makefile &&
sedit 's/ucb/bin/' Makefile &&
sedit 's/= termlib/= ncurses/' Makefile &&
make &&
prepare_install &&
make install
) > $C_FIFO 2>&1

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.

'''Note''' - [[BUILD]] scripts must execute inside a (), called a subshell invocation, construct and output is always directed to a named pipe (aka FIFO). Therefor all [[BUILD]] files take the follwing form:

(
# commands are put here
) > $C_FIFO 2>&1 # $C_FIFO holds the name of a fifo in /tmp used for 'voyeur'

=== The POST_BUILD script ===

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

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

=== The POST_INSTALL script ===

[[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>)

cd /usr/lib/gcc-lib/$BUILD/$VERSION &&
ln -sf /usr/bin/cpp cpp &&
cd /lib/ &&
ln -sf /usr/bin/cpp cpp &&
if [ ! -e /usr/bin/cc ] ; then
ln -s gcc /usr/bin/cc
fi

== Package Removal Scripts ==

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.

=== The PRE_REMOVE script ===

[[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>)

CENTRALIZED=/etc/sgml/catalog
DOCBOOK_INSTALL_DIR=/usr/share/sgml/docbook/$VERSION
install-catalog -r $CENTRALIZED $DOCBOOK_INSTALL_DIR/catalog

=== The POST_REMOVE Script ===

[[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>)

install-info --delete as --info-dir /usr/info
install-info --delete bfd --info-dir /usr/info
install-info --delete binutils --info-dir /usr/info
install-info --delete configure --info-dir /usr/info
install-info --delete gasp --info-dir /usr/info
install-info --delete gprof --info-dir /usr/info
install-info --delete ld --info-dir /usr/info

or: (<code>/var/lib/lunar/moonbase/compilers/php/POST_REMOVE</code>)

if module_installed apache; then
cp /etc/httpd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpd/httpd.conf
rm -f /tmp/httpd.conf
elif module_installed apache_mod_ssl; then
cp /etc/httpsd/httpd.conf /tmp/httpd.conf
grep -v "LoadModule php4_module" /tmp/httpd.conf |
grep -v "AddModule mod_php4.c" > /etc/httpsd/httpd.conf
rm -f /tmp/httpd.conf
fi

Module Writing

2006-08-28T20:54:08Z

V3rt1g0: /* Before you start */ cleaning up a bit

__TOC__

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

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

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

==Starting the module==

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

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

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

MODULE=mymodule
VERSION=1.0
SOURCE=$MODULE-$VERSION.tar.bz2
SOURCE_URL=http://my.site.org/files/
SOURCE_VFY=sha1:e96df66f703c5ab1a295e216b5035ee14d6202b2
WEB_SITE=http://my.site.org/
ENTERED=20050808
UPDATED=20050808
SHORT="Makes module writing easy"

cat<<EOF
MyModule is a simple tool to explain module writing in
detail. It doesn't actually exist but is used as an example
for educational purposes.
EOF

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

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

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

== Module Format ==

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

Module Guidelines

2006-08-28T20:09:48Z

V3rt1g0: /* DETAILS */

__TOC__

== Generic ==
These guidelines apply to all of a module's files.
* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.

== DETAILS ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html shown] to be less prone to key clashes than the MD5 algorithm.
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.
* Avoid using the module's name in the SHORT field.
** e.g. instead of SHORT="MyModle is an application designed to take over the world." you should use SHORT="an application designed to take over the world"
** You are encouraged however to start the long description off with the modules name. So in the example above the long description might be "MyModule is a GTK+-2 application designed to take over the world. It features mind-control and cute, fuzzy kittens." (wrapped to 72 characters characters of course.) This way the output of [[lvu what]] is presented nicely to the user.
* Always align the equal signs (=) vertially within the file. "=" should be at character position 17, as this allows for the (optional) variable SOURCE_DIRECTORY= to be added later if needed and have it still be lined up with the rest of the content already in the file.

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

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

== CONFIGURE ==

== PRE_BUILD ==

== BUILD ==

* Don't install files after calling '''devoke_installwatch'''.

== POST_BUILD ==

* Don't install any files into the system.

== POST_INSTALL ==

* Don't install any files into the system.

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-28T20:02:12Z

V3rt1g0: /* DETAILS */

__TOC__

== Generic ==
These guidelines apply to all of a module's files.
* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.

== DETAILS ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html shown] to be less prone to key clashes than the MD5 algorithm.
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.
* Avoid using the module's name in the SHORT field.
** e.g. instead of SHORT="MyModle is an application designed to take over the world." you should use SHORT="an application designed to take over the world"
** You are encouraged however to start the long description off with the modules name. So in the example above the long description might be "MyModule is a GTK+-2 application designed to take over the world. It features mind-control and cute, fuzzy kittens." (wrapped to 72 characters characters of course.) This way the output of [[lvu what]] is presented nicely to the user.

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

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

== CONFIGURE ==

== PRE_BUILD ==

== BUILD ==

* Don't install files after calling '''devoke_installwatch'''.

== POST_BUILD ==

* Don't install any files into the system.

== POST_INSTALL ==

* Don't install any files into the system.

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-28T19:59:39Z

V3rt1g0: /* DETAILS */

__TOC__

== Generic ==
These guidelines apply to all of a module's files.
* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.

== DETAILS ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html shown] to be less prone to key clashes than the MD5 algorithm.
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.
* Avoid using the module's name in the SHORT field.
** e.g. instead of SHORT="MyModle is an application designed to take over the world." you should use SHORT="an application designed to take over the world"
** You are encouraged however to start the long description off with the modules name. So in the example above the long description might be "MyModule is a GTK+-2 application designed to take over the world. It features mind-control and cute, fuzzy kittens."

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

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

== CONFIGURE ==

== PRE_BUILD ==

== BUILD ==

* Don't install files after calling '''devoke_installwatch'''.

== POST_BUILD ==

* Don't install any files into the system.

== POST_INSTALL ==

* Don't install any files into the system.

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-28T19:56:10Z

V3rt1g0: /* DETAILS */

__TOC__

== Generic ==
These guidelines apply to all of a module's files.
* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.

== DETAILS ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html shown] to be less prone to key clashes than the MD5 algorithm.
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.
* Avoid using the module's name in the SHORT field.
** e.g. instead of SHORT="MyModle is an application designed to take over the world." you should use SHORT="an application designed to take over the world"

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

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

== CONFIGURE ==

== PRE_BUILD ==

== BUILD ==

* Don't install files after calling '''devoke_installwatch'''.

== POST_BUILD ==

* Don't install any files into the system.

== POST_INSTALL ==

* Don't install any files into the system.

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-28T19:48:33Z

V3rt1g0: /* DEPENDS */

__TOC__

== Generic ==
These guidelines apply to all of a module's files.
* Never use tabs. '''Use spaces''' instead.
* Use '''72 columns''' as a maximum width whenever possible (but always in the long description in the [[DETAILS]] file!).
* '''Respect the MAINTAINER''' value. Don't modify maintained modules unless you first consult the listed maintainer.

== DETAILS ==

* Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
**The SHA1 algorithm has been [http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.html shown] to be less prone to key clashes than the MD5 algorithm.
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.

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

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

== CONFIGURE ==

== PRE_BUILD ==

== BUILD ==

* Don't install files after calling '''devoke_installwatch'''.

== POST_BUILD ==

* Don't install any files into the system.

== POST_INSTALL ==

* Don't install any files into the system.

== PRE_REMOVE ==

== POST_REMOVE ==

Module Guidelines

2006-08-28T19:39:16Z

V3rt1g0: /* DEPENDS */

Module Guidelines

2006-08-28T19:34:52Z

V3rt1g0: /* DEPENDS */

Module Guidelines

2006-08-28T19:32:39Z

V3rt1g0: /* DEPENDS */

Module Guidelines

2006-08-28T19:32:11Z

V3rt1g0: /* DEPENDS */

Module Guidelines

2006-08-28T19:30:48Z

V3rt1g0: /* DEPENDS */ No logic in depends message

Module Guidelines

2006-08-28T19:19:28Z

V3rt1g0: /* DEPENDS */

Module Guidelines

2006-08-28T19:09:50Z

V3rt1g0: /* DETAILS */

Module Guidelines

2006-08-28T18:57:16Z

V3rt1g0: /* CONFLICTS */

Module Guidelines

2006-08-28T18:54:26Z

V3rt1g0: /* DEPENDS */

Module Guidelines

2006-08-28T18:49:08Z

V3rt1g0: /* DEPENDS */ make this a bit clearer as to what it means

Module Guidelines

2006-08-28T16:35:57Z

V3rt1g0: /* Generic */

Module Guidelines

2006-08-28T16:32:33Z

V3rt1g0: /* Generic */ tweaks

__TOC__

== Generic ==

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

== DETAILS ==

* Use '''sha1:''' instead of ''md5:'' for SOURCE_VFY values.
* Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
* Prefer '''tar.bz2''' over '''tar.gz''' tarballs (as it saves space/traffic) and prefer '''tar.gz''' over '''zip''' (or '''rar''') packages.

== DEPENDS ==

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

== CONFLICTS ==

* Remember to add a CONFLICTS to both modules that conflict with each other.

== CONFIGURE ==

== PRE_BUILD ==

== BUILD ==

* Don't install files after calling '''devoke_installwatch'''.

== POST_BUILD ==

* Don't install any files into the system.

== POST_INSTALL ==

* Don't install any files into the system.

== PRE_REMOVE ==

== POST_REMOVE ==

Module Writing

2006-08-28T16:31:02Z

V3rt1g0: /* Starting the module */ tweak the example

__TOC__

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

==Before you start==

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

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

==Starting the module==

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

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

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

MODULE=mymodule
VERSION=1.0
SOURCE=$MODULE-$VERSION.tar.bz2
SOURCE_URL=http://my.site.org/files/
SOURCE_VFY=sha1:e96df66f703c5ab1a295e216b5035ee14d6202b2
WEB_SITE=http://my.site.org/
ENTERED=20050808
UPDATED=20050808
SHORT="Makes module writing easy"

cat<<EOF
MyModule is a simple tool to explain module writing in
detail. It doesn't actually exist but is used as an example
for educational purposes.
EOF

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

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

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

== Module Format ==

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

Install XOrg7

2006-05-30T15:38:58Z

V3rt1g0: /* Installing XOrg 7.x */ ppl -> people

=The path to XOrg7=

==Upgrading from XOrg 6.x==

Currently, the XOrg7 module needs you to do a few things manually if you upgrade from an earlier XOrg 6.x installation. You have to adhere to the following steps. If you do not listen to our advice then you're on your own.

*Remove the old XOrg
: <code>lrm XOrg</code>
Note: XOrg conflicts with XOrg7. Thus it would've been removed anyway. But we need to do more ...

*Backup the old /etc/X11 (with your old xorg.conf)
: <code>mv /etc/X11 /etc/X11.old</code>

*Remove the old XOrg installation remains
: <code>rm -fr /usr/X11R6</code>

*Remove some old symlinks
**<code>rm /usr/X11</code>
**<code>rm /usr/include/X11</code>
**<code>rm /usr/lib/X11</code>
**<code>rm /usr/include/GL</code>

==Installing XOrg 7.x ==
*Add the XOrg7 profile to the alias file: 
edit /var/lib/lunar/moonbase/aliases and add XOrg7 to the %X line...

*First of all you need to check out crater... (we are developping X11R7 in an "experimental" branch of the moonbase as to avoid people messing up their production boxes)
** <code>svn co https://username@foo-projects.org/svn/lunar/moonbase/branches/crater crater</code> Then copy the XOrg7 directory to your zlocal
** or fetch the [http://merlin.ugent.be/lunar/xorg7.0.tar.gz xorg7.0-tarball] or the [http://merlin.ugent.be/lunar/xorg7.1.tar.gz the xorg7.1-tarball] from http://merlin.ugent.be/lunar/ and copy the extracted files to your $MOONBASE/zlocal

*For now, you may use the XOrg7 profile for it: 
<code>lin XOrg7</code>

==Installation notes==

XOrg7 is installing to /usr by default and ''NOT'' to /usr/X11R7 or any other prefix inside /usr. The [http://www.pathname.com/fhs Filesystem Hierarchy Standard] does not allow that. All major linux distributions are following the FHS and have adjusted their builds accordingly:

*[http://lists.debian.org/debian-devel-announce/2006/04/msg00010.html Debian]
*[http://wiki.archlinux.org/index.php/Xorg7 Arch Linux]
*[http://gentoo-wiki.com/HOWTO_Modular_Xorg Gentoo]

You may however set an arbitary prefix for XOrg incase you do not want it to install to /usr. You may do so by running the following command: 
: <code>lunar set X11R7_PREFIX=/your/prefix/here</code> 
The most commonly used prefix would be /usr/X11R7, however, some other prefix inside /opt is entirely possible.

The XOrg7 profile is going to create some symlinks on your system: 
: <code>/usr/X11 -> $MODULE_PREFIX; /usr by default </code>
: <code>/usr/X11R6 -> $MODULE_PREFIX; /usr by default</code> 
The X11R6 symlink is there for compatibility reasons. Many of the older and even some of the newer packages inside the moonbase have a hardcoded path pointing to /usr/X11R6 inside their source trees. Keeping the symlink prevents them from breaking apart.

==Annoyances==
The latest NVIDIA driver doesn't support the current [http://lists.freedesktop.org/archives/xorg/2006-May/015396.html ABI changes] in X11R7.1. This means you will be lacking text in some programs. Gtk+-2 programs do not show this problem (though firefox does). Solution? Some have suggested that turning of the XRendeR acceleration should work (so add: Option "RenderAccel" "false"). If that doesn't work i guess you'll have to use the opensource driver (xf86-video-nv) [http://www.nvnews.net/vbulletin/showthread.php?t=70570 threads] [http://www.nvnews.net/vbulletin/showthread.php?t=70476 on nvidia forum].

==Missing modules from the XOrg 7.x modular tree==

Despite our best efforts to give you the whole XOrg 7.x modular tree as modules to install there are still many of them left untouched either because they are not important to run a full featured X environment or nobody had the time to add them yet. As always contribution are welcome and appreciated:

*x11-apps
**appres - list X application resource database
**lbxproxy - Low BandWidth X proxy
**luit - Convert terminal i/o from legacy encodings to UTF-8
**mkcfm - create summaries of CID font metric files
**oclock - round X clock
**proxymngr - proxy manager service
**scripts - run X command on another system via rsh
**sessreg - Register X sessions in system utmp/utmpx databases
**showfont - show information about X font from font server
**twm - simple window manager
**viewres - graphical class/resource browser for Xt
**xbiff - watch mailboxes for new message delivery
**xclipboard - X clipboard manager
**xdbedizzy - DBE sample
**xditview - display ditroff output
**xdm - list X application resource database
**xf86dga - known unto god
**xfd - display all the characters in an X font
**xfindproxy - locate proxy services
**xfontsel - point and click selection of X11 font names
**xfsinfo - X font server information utility
**xfwp - X Firewall Proxy
**xgc - X graphics demo
**xkbprint - print an XKB keyboard description
**xkill - kill a client by its X resource
**xload - system load average display for X
**xlogo - Draw [old] X logo
**xlsclients - list client applications running on a display
**xmag - magnify parts of the screen
**xphelloworld - Xprint sample applications
**xprehashprinterlist - Rehash list of Xprint printers
**xrx - "Broadway"
**xsetmode - set the mode for an X Input device
**xsetpointer - set an X Input device as the main pointer
**xsm - X Session Manager
**xstdcmap - X standard colormap utility
**xvidtune - video mode tuner for Xorg
*x11-data
COMPLETE
*x11-doc
**xorg-docs
**xorg-sgml-doctools
*x11-driver
**xf86-video-sunbw2
**xf86-video-suncg3
**xf86-video-suncg6
**xf86-video-suncg14
**xf86-video-sunffb
**xf86-video-sunleo
**xf86-video-suntcx
**xf86-video-tdfx
**xf86-video-tga
**xf86-video-trident
**xf86-video-tseng
*x11-extras
COMPLETE
*x11-font
**font-cronyx-cyrillic
**font-daewoo-misc
**font-dec-misc
**font-ibm-type1
**font-isas-misc
**font-jis-misc
**font-micro-misc
**font-misc-cyrillic
**font-misc-ethiopic
**font-misc-meltho
**font-mutt-misc
**font-schumacher-misc
**font-screen-cyrillic
**font-winitzki-cyrillic
*x11-lib
**libAppleWM - platform specific libraries: [MacOS]
**libWindowsWM - platform specific libraries: [Win32]
*x11-proto
**windowswmproto - platform specific protocol headers [Win32]
*x11-util
**lndir
*xserver
COMPLETE

Help:Editing

2005-03-06T15:50:39Z

V3rt1g0:

==General==
To edit a page, click on the "'''Edit this page'''" (or just "'''edit'''") link at one of its edges. This will bring you to a page with a text box containing the ''[[wikitext]]'': the editable source code from which the server produces the webpage.

After adding to or changing the wikitext it is useful to press "Show preview", which produces the corresponding webpage in your browser but does not make it publicly available yet (not until you press "Save"). Errors in formatting, links, tables, etc., are often much easier to discover from the rendered page than from the raw wikitext.

If you are not satisfied you can make more changes and preview the page as many times as necessary. Then write a short [[Help:Edit summary|edit summary]] in the small text field below the edit-box and when finished press "Save". Depending on your system, pressing the "Enter" key while the edit box is not active (i.e., there is no typing cursor in it) may have the same effect as pressing "Save".

You may find it more convenient to copy and paste the text first into your favorite [[en:text editor|text editor]], edit and spell check it there, and then paste it back into your [[en:web browser|web browser]] to preview. This way, you can also keep a local backup copy of the pages you have edited. It also allows you to make changes offline, but before you submit your changes, ''please make sure nobody else has edited the page'' since you saved your local copy (by checking the [[Help:page history|page history]]), otherwise you may accidently revert someone else's edits. If someone ''has'' edited it since you copied the page, you'll have to merge their edits into your new version (you can find their specific edits by using the "[[Help:diff|diff]]" feature of the page history). These issues are handled automatically by the Mediawiki software if you edit the page in your web browser.

== Minor edits ==
When editing a page, a logged-in user has the option of flagging the edit as a "minor edit". This feature is important, because users can choose to ''hide'' minor edits in their view of the Recent Changes page, to keep the volume of edits down to a manageable level.

When to use this is somewhat a matter of personal preference. The rule of thumb is that an edit of a page that consists of spelling corrections, formatting, and minor rearranging of text should be flagged as a "minor edit". A major edit is basically something that makes the entry worth revisiting for somebody who wants to watch the article rather closely. So any "real" change, even if it is a single word, should be flagged as a "major edit".

The reason for not allowing a user who is not logged in to mark an edit as minor is that vandalism could then be marked as a minor edit, in which case it would stay unnoticed longer. This limitation is another reason to log in.

Credits: text taken from WikiMedia's [http://meta.wikimedia.org/wiki/Help:Editing help page]. Visit there for even more editing help.

Help:Editing

2005-03-06T15:40:26Z

V3rt1g0:

User:V3rt1g0

2005-03-06T15:09:17Z

V3rt1g0:

#REDIRECT [[Wikipedia:en:User:v3rt1g0]]

User:V3rt1g0/standard.css

2005-03-05T16:30:33Z

V3rt1g0:

.file {
color: red;
}

Moonbase

2005-03-05T16:12:18Z

V3rt1g0:

The moonbase is the complete collection of all the software packages (modules) that Lunar-Linux offers its users. It is organized in a hierarchical structure of directories and files; usually found on the user's system at <code>/var/lib/lunar/moonbase</code>. Generically speaking, the moonbase is just a directory with stuff (sub-directories and files) inside it.

The moonbase's first level of structure/organization is a section. A section is a name that serves to classify and organize a group of modules into logical partitions. Each section is simply a sub-directory that resides right below the root of the moonbase. So, if the section's name is "games," it will be found at <code>/var/lib/lunar/moonbase/games</code> and hopefully will contain all of the game related modules.

Below each section is a collection of sub-directories. Each of these sub-directories represent a single module that "belongs" to that section of the moonbase. A module, to be a bit simplistic, is a set of one more more files under a directory that are "instructions" to perform a task. Namely, instructions to compile and then install what was compiled onto the user's file-system. So if we had a module named FooGame that was located in the "games" section of the moonbase, we would find a directory called FooGame at <code>/var/lib/lunar/moonbase/games/FooGame</code>.

To summarize, installable software packages are called modules. The collection of all of the modules is called the moonbase, which is simply a directory containing logical sections (sub-directories) which, in turn, contain the modules directories.

Moonbase
|
|--Sections
|
|--Modules
|
|--Files (as described elsewhere)