[Lunar-commits] r15518 - lunar-doc/trunk/lunar-manual
ca3sar
ca3sar at lunar-linux.org
Tue Jun 28 21:42:49 UTC 2005
Author: ca3sar
Date: 2005-06-28 21:42:44 +0000 (Tue, 28 Jun 2005)
New Revision: 15518
Modified:
lunar-doc/trunk/lunar-manual/Lunar_Book.tex
lunar-doc/trunk/lunar-manual/chapter5.tex
lunar-doc/trunk/lunar-manual/chapter6.tex
Log:
Integrated elaines module howto and added some stuff to the fglrx section
Modified: lunar-doc/trunk/lunar-manual/Lunar_Book.tex
===================================================================
--- lunar-doc/trunk/lunar-manual/Lunar_Book.tex 2005-06-28 19:46:45 UTC (rev 15517)
+++ lunar-doc/trunk/lunar-manual/Lunar_Book.tex 2005-06-28 21:42:44 UTC (rev 15518)
@@ -19,8 +19,9 @@
\begin{document}
-\title{ Lunar Linux Manual}
-\author{Sofar, Tchan, Nestu, Ca3sar}
+\title{ Lunar Linux\footnote{Lunar Linux is Copyleft © 2002, 2003, 2004, Lunar Linux Team
+LINUX® is a registered trademark of Linus Torvalds.} Manual}
+\author{Sofar, Tchan, Nestu, Elaine, Ca3sar}
\maketitle
\newpage
@@ -34,7 +35,7 @@
%sofar: this is ur job ?
This book is a try to get the library on www.lunar-linux.org into $ \LaTeX$ form. Further more we (will) try to update most infos to the new 1.5.0 ISO, especially the install section and provide some screenshots for eyecandy. Everything else is a matter of time and effort. For a Lunar beginner a manual like this one has the advantage of a being a better compendium and its better to print out than the html on the webby. Though the chosen format is not as flexible as html is, and new things and changes have to be "compiled in" by someone, as long as the devs are working on the html basis. So this requires constant maintaining or some sections will date out quite soon. Perhaps it would be enough to make a docu changelog by the devs, to let us know whats new.\par
-The manual is meant to cause a laerning effect on the reader. So i wont describe every detail, your intended to think for yourself. Lunar is an excellent distro to learn Linux the right way. In the troubleshooting chapter you will find help for self-help.\par
+The manual is meant to cause a learning effect on the reader. So we wont describe every detail, your intended to think for yourself. Lunar is an excellent distro to learn Linux. In the troubleshooting chapter you will find help for self-help.\par
Many chapters are worked in How-To`s from the library, so nestu, sofar, tchan here is the answer why you appear as author of this book foremost. Im replaying most steps on a qemu installation and update certain passages, as done with the install docu, that \_really\_ wasn't up to date ... \par
Modified: lunar-doc/trunk/lunar-manual/chapter5.tex
===================================================================
--- lunar-doc/trunk/lunar-manual/chapter5.tex 2005-06-28 19:46:45 UTC (rev 15517)
+++ lunar-doc/trunk/lunar-manual/chapter5.tex 2005-06-28 21:42:44 UTC (rev 15518)
@@ -247,16 +247,31 @@
\subsection{ATI Accelerators}
-Owners of an ATI graphics adapter need the fglrx module. Do a
+First you need to make shure, your kernel matches all requirements.\footnote{The following is taken from the fglrx howto found at www.rage3d.com written by Peter Gracar (who.knows AT email DOT si)} So do a \textit{lin -rc linux-2.X}, use your favourite tool to investigate kernel konfigurationand enable the following options:
+\begin{itemize}
+\item /dev/agpgart under ``character devices''
+\item MTRR (Memory Type Range Register) under ``processor type and features''
+ \end{itemize}
+
+Then disable:
+
+\begin{itemize}
+\item Direct Rendering Manager (XFree86 DRI support) under ``character devices''
+\item Kernel debugging under ``Kernel hacking''
+ \end{itemize}
+
+Thats it. We will asume the build-in AGPGart driver supports your mainboard. If you encounter error regarding ADPGart, please check the rage3d.com How-To. \par
+Further you need the fglrx module. Do a
+
\begin{center}
\textit{lin fglrx}
\end{center}
and the newest module will be installed. To check if it was successfully loaded you can look if \textit{lsmod} shows fglrx. The next step is to configure XOrg for the driver. The module provides the \textit{fglrxconfig} wizard. It replaces your /etc/X11/xorg.conf by one customized for the fglrx driver. Now you should be up and running. By today the closed source drivers doesn't support the composite extension (shadows, transparency). If you want it, use the radeon open source driver. \par
+
You can test 3d Acceleration by \textit{fglrxinfo} and set the gamma values by \textit{fglrxgamma}. For a GUI driven menu you can use \textit{fireglcontrol}. When running \textit{fglrxinfo }you should see something like that:
-
\begin{flushleft}
root at Schroedinger / \# \textit{fglrxinfo} \\
display: :0.0 screen: 0 \\
@@ -270,7 +285,6 @@
If you encounter problems, take a look at \textit{www.rage3d.com}. Under forum/linux/driver you will find a discussion of many users of this driver. Even ATI developers show up sometimes! You will also find a How-To there. \par
Take a look if the symlinks in /usr/X11R6/lib/ :
-
\begin{flushleft}
libGL.so $\rightarrow$ /usr/X11R6/lib/libGL.so.1.2 \\
libGL.so.1 $\rightarrow$ /usr/X11R6/lib/libGL.so.1.2\\
@@ -280,7 +294,6 @@
libGLw.so.1 $\rightarrow$ libGLw.so.1.0\\
\end{flushleft}
-
exist. \par
For diagnostic, examine /var/log/Xorg.0.log, and look for entries with [EE] at the beginning.
Modified: lunar-doc/trunk/lunar-manual/chapter6.tex
===================================================================
--- lunar-doc/trunk/lunar-manual/chapter6.tex 2005-06-28 19:46:45 UTC (rev 15517)
+++ lunar-doc/trunk/lunar-manual/chapter6.tex 2005-06-28 21:42:44 UTC (rev 15518)
@@ -7,4 +7,376 @@
\section{Places}
-\section{Modules}
\ No newline at end of file
+\section{Modules}
+\subsection{Module Design}
+
+In lunar parlance, software packages are called modules. The collection of all modules is the moonbase, which is simply a directory (usually /var/lib/lunar/moonbase) containing sections (i.e. directories) which in turn contain the module directories. \par
+
+A module is simply a directory containing the scripts necessary to build a software package, and optionally configuration files which may be needed in /etc. 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. \par
+
+\begin{itemize}
+\item DETAILS sets version, source URL(s) and other critical data
+\item DEPENDS specifies required and optional packages
+\item CONFLICTS specifies modules which must(will) be removed by module
+\item CONFIGURE interactive script where build options can be set
+\item PRE\_BUILD most often used for patching, unpacking addional source tarballs
+\item BUILD runs necessary variations on: configure; make; make install
+\item POST\_BUILD install configuration scripts and data.
+\item POST\_INSTALL messages, notes more cleanups, configuration fixes
+\item PRE\_REMOVE used by 'lrm'; actions which must preceed removal
+\item POST\_REMOVE used by 'lrm'; actions which must follow removal
+ \end{itemize}
+
+\subsection{Package Build and Install Scripts}
+
+The following scripts are used by \textit{lin} (or indirectly by \textit{lunar}) when building modules. \par
+
+\subsubsection{The DETAILS script}
+
+Every module is required to have at least a DETAILS file. A minimal DETALS may appear as follows : (/var/lib/lunar/moonbase/editors/emacs/DETAILS) \par
+
+\begin{flushleft}
+ MODULE=emacs\\
+ VERSION=21.3\\
+ SOURCE=\$MODULE-\$VERSION.tar.gz\\
+SOURCE\_DIRECTORY=\$BUILD\_DIRECTORY/\$MODULE-\$VERSION\\
+ SOURCE\_URL=\$GNU\_URL/\$MODULE/\$SOURCE\\
+ SOURCE\_URL=ftp://ftp.gnu.org/pub/gnu/\$MODULE/\$SOURCE\\
+ SOURCE\_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420\\
+ WEB\_SITE=http://www.gnu.org/software/emacs\\
+ ENTERED=20010922\\
+ UPDATED=20020529\\
+ SHORT="Emacs is the extensible, self-documenting real-time display editor."\\
+cat << EOF\\
+Emacs is the extensible, customizable, self-documenting real-time display editor. \\
+EOF
+\end{flushleft}
+
+With comments, default values:
+
+\begin{flushleft}
+ 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/\$SOURCE \# Download URL\\
+ SOURCE\_URL[1]=ftp://ftp.gnu.org/pub/gnu/\$MODULE/\$SOURCE \# Alternate URL(s)\\
+ SOURCE\_VFY=md5:a0bab457cbf5b4f8eb99d1d0a3ada420 \# Sets md5 hash or pgp/gpg sig url\\
+ WEB\_SITE=http://www.gnu.org/software/emacs \# 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="Emacs is the extensible, self-documenting real-time display editor."\\
+cat << EOF\\
+Emacs is the extensible, customizable, self-documenting real-time display editor. \\
+EOF
+\end{flushleft}
+
+\subsubsection{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. \par
+
+\textbf{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. \par
+
+\textbf{Note} By convention Lunar does not include the X Window System (xfree86) 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. \par
+
+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 ./configure (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 : (/var/lib/lunar/moonbase/devel/subversion/DEPENDS)
+%someone PLS make a table here. looks 10000 times better
+\begin{flushleft}
+depends zlib $\&\&$\\
+depends openssl $\&\&$\\
+optional\_depends "db4" "--with-berkeley-db" "" "for creating local repositories"\\
+%# \^ \^ \^ \^\\
+%# | | | |\\
+# optional package if "Y" if "N" explanatory comment\\
+# { ./configure strings }\\
+\end{flushleft}
+
+\subsubsection{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 : (/var/lib/lunar/moonbase/editors/elvis/CONFLICTS)
+
+\begin{flushleft}
+conflicts vim
+\end{flushleft}
+
+\subsubsection{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 : (/var/lib/lunar/moonbase/crypto/gnupg/CONFIGURE)
+
+\begin{flushleft}
+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\\
+\end{flushleft}
+
+\subsubsection{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 : (/var/lib/lunar/moonbase/doc-tools/html2db/PRE\_BUILD)
+
+\begin{flushleft}
+mk\_source\_dir \$SOURCE\_DIRECTORY $\&\&\$\
+unpack \$SOURCE $ \&\&$\\
+cd \$MODULE\\
+unpack \$SOURCE2\\
+cd tidy\\
+patch\_it \$SOURCE\_CACHE/\$SOURCE3 0\\
+cd /usr/src/\$MODULE\\
+\end{flushleft}
+
+\subsubsection{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:
+
+\begin{flushleft}
+ ./configure --build=\$BUILD $\backslash$ \\
+ --prefix=/usr $\backslash$ \\
+ --sysconfdir=/etc $\backslash$ \\
+ --localstatedir=/var $\backslash$ \ \\
+ --infodir=/usr/share/info $\backslash$ \\
+ --mandir=/usr/share/man $\backslash$ \\
+ \$OPTS \\
+\end{flushleft}
+
+Next, default\_build(): calls default\_make which executes:
+
+\begin{flushleft}
+ make \&\&\\
+ make install\\
+\end{flushleft}
+
+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 : (/var/lib/lunar/moonbase/archive/gzip/BUILD)
+
+\begin{flushleft}
+(
+
+./configure --build=\$BUILD $\backslash$ \\
+ --prefix=/usr $\backslash$ \\
+ --bindir=/bin $\backslash$ \\
+ --infodir=/usr/share/info $\backslash$ \\
+ --mandir=/usr/share/man $\&\&$ \\
+make $\&\&$\\
+prepare\_install \&\&\\
+make bindir=/bin install\\
+
+) > \$C\_FIFO 2>\\&1\\
+\end{flushleft}
+
+and : (/var/lib/lunar/moonbase/editors/ex/BUILD)
+
+\begin{flushleft}
+(\\
+ 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\\
+\end{flushleft}
+
+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. \par
+\textbf{Note} BUILD scripts must execute inside a () (subshell invocation) construct and output is always directed to a named pipe (aka FIFO). Therefor all BUILD files take the follwing form:
+
+\begin{flushleft}
+(\\
+ command(s)\\
+) > \$C\_FIFO 2>\&1 \# \$\\
+
+C\_FIFO holds the name of a fifo in /tmp used for 'voyeur'\\
+\end{flushleft}
+
+\subsubsection{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 /etc. An example script would be : (/var/lib/lunar/moonbase/net/samba/POST\_BUILD)
+
+\begin{flushleft}
+if [ ! -d /etc/samba/private ]; then\\
+ mkdir -p /etc/samba/private\\
+ chmod 700 /etc/samba/private\\
+fi\\
+\end{flushleft}
+
+\subsubsection{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 : (/var/lib/lunar/moonbase/compilers/gcc/POST\_INSTALL)
+
+\begin{flushleft}
+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 $\&\&$\\
+
+rm\_source\_dir /usr/src/gcc-\$VERSION-BUILD $\&\&$\\
+rm\_source\_dir /usr/src/gcc-\$VERSION $ \&\&$\\
+
+ldconfig\\
+\end{flushleft}
+
+\subsection{Package Removal Scripts}
+
+Module removal is handled by 'lrm(8)'. 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. \par
+
+\subsubsection{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 : (/var/lib/lunar/moonbase/mail/courier-imap/PRE\_REMOVE)
+
+\begin{flushleft}
+if [ -x /etc/init.d/imapd ]; then\\
+ /etc/init.d/imapd stop\\
+fi\\
+
+chkconfig --del imapd\\
+\end{flushleft}
+
+\subsubsection{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 \\ (/var/lib/lunar/moonbase/devel/binutils/POST\_REMOVE) :
+
+\begin{flushleft}
+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\\
+\end{flushleft}
+
+or : (/var/lib/lunar/moonbase/compilers/php/POST\_REMOVE)
+
+\begin{flushleft}
+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\\
+ /usr/sbin/apachectl graceful\\
+
+
+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\\
+ /etc/init.d/apache\_modssl.sh restart\\
+\linebreak
+fi
+\end{flushleft}
+\subsection{Versioned scripts}
+
+To provide support for multiple simultaneous versions of a given package, (and to eas migration between versions) lunar supports a module/version syntax.
+Designing versioned scripts \par
+
+\textbf{Note}: Versioning is not a panacea, while certain problems can be solved by using versioning, it is important both to understand how versions are implemented in lunar as well as the specific implications for a given package of the presence of multiple versions of specific libraries and executables. \par
+
+Alternate versions of modules are created by adding a version subdirectory under the module's main directory. For example the gcc directory contains the subdirectories for gcc versions 3.3 and 3.3.1; gcc/3.3.1 contains all of the same files needed to build the default version (3.2.3 at the time of this writing). \par
+
+\begin{flushleft}
+thing:/lp/moonbase/compilers/gcc\$ \textit{ls -lr }\\
+total 26\\
+-rwxr-xr-x 1 elaine users 254 Dec 3 2002 PRE\_BUILD\\
+-rwxr-xr-x 1 elaine users 228 Aug 20 2002 POST\_REMOVE\\
+-rwxr-xr-x 1 elaine users 490 Oct 17 2002 POST\_INSTALL\\
+-rwxr-xr-x 1 elaine users 966 Apr 25 16:54 DETAILS\\
+-rwxr-xr-x 1 elaine users 1119 Feb 1 2003 CONFIGURE\\
+-rwxr-xr-x 1 elaine users 1123 Apr 25 16:54 BUILD\\
+drwxr-xr-x 3 elaine users 248 Sep 12 09:18 3.3.1\\
+drwxr-xr-x 3 elaine users 248 Sep 12 09:18 3.3\\
+
+thing:/lp/moonbase/compilers/gcc\$ \textit{ls -lr 3.3.1}\\
+total 25\\
+-rwxr-xr-x 1 elaine users 254 Sep 7 18:09 PRE\_BUILD\\
+-rwxr-xr-x 1 elaine users 228 Sep 7 18:09 POST\_REMOVE\\
+-rwxr-xr-x 1 elaine users 582 Sep 7 18:09 POST\_INSTALL\\
+-rwxr-xr-x 1 elaine users 956 Sep 7 18:09 DETAILS\\
+-rwxr-xr-x 1 elaine users 1119 Sep 7 18:09 CONFIGURE\\
+-rwxr-xr-x 1 elaine users 1211 Sep 7 18:09 BUILD\\
+\end{flushleft}
+
+\subsection{Module/version requirements}
+\begin{itemize}
+\item Naming rules: module/version
+ \subitem required: Alternate version modules must have same MODULE name
+ \subitem required: Directory and variable VERSION = "[0-9]*" (must begin with an integer)
+ \subitem preferred: Use shortest reasonable /version string (e.g. 0.9.5, 0.9.5-test)
+\item Installation requirements
+ \subitem preferred: Alternate version modules install in /opt/lunar/module/v.v or similar location
+ \subitem required: Data objects which functionally differ between versions must not conflict/overwrite
+ \subitem allowed: functionally identical supporting data (e.g. /usr/share/doc/module) may overwrite if this is deemed safe in a given instance
+\item DETAILS script
+ \subitem The MODULE= variable must be changed to module/version syntax. Example: \\
+ MODULE=gcc/3.3.1
+ \subitem \$MODULE and \${MODULE} references are disallowed in /v.v/DETAILS files
+ \subitem Works: SOURCE=gcc-\$VERSION.tar.bz2
+ \subitem Breaks: SOURCE=\${MODULE}-\$VERSION.tar.bz2
+\item BUILD script : May need no more changes than adjusting ./configure --options. Example:\\
+ ./configure --prefix=/opt/lunar/gcc/3.3.1 \
+\item DEPENDS script: In complex systems (e.g. desktops) many dependencies may need to be converted to module/v.v form.
+\end{itemize}
+
+\subsection{Discussion: Why versioned modules}
+
+Many key applications install themselves with full version information, perl, emacs and gcc would all be good examples. They build private arch-version specific libraries allowing multiple versions to be simultaneously installed. \par
+
+Unfortunately it's not, or at least not always simple. Many software builds now seem to install a mix of libraries which may be accessible thru ldconfig and private libraries known by their install paths, and it's not always clear which is which (and some sometimes seem to be both). \par
+
+Outline of the steps needed to get gnome2/2.4.0 working.
+\begin{enumerate}
+\item ***key*** Backup of /opt/lunar/gnome/2 so that I could roll-back to prior state and test bugs in the build.
+ \item Development of a perl script to roll back /var/state/lunar/packages* files to match the prior-state gnome(2.2). --- necessary because mismatched versions in the packages files cause script breakage.
+\item Isolation of the packages which needed to be rewritten in /version notation. I started with the list which Nick provided for gnome 2.4 build and added a few more which were pulled in as dependencies and caused breakage if not /versioned. *NOTE* this step is predictably imperfect, my gnome configuration was only what had been installed by 'lin gnome2' when it was version 2.2, with not much optional deps selected. different optional deps and/or added gnome 'stuff' will probably add some things to this list.
+\item Moving some things out of /usr, into /opt. About 3 of the gnome2 modules used ./configure --prefix=/usr. Nick indicated that this had been neccessary only because the first time through he'd been unable to get them working in /opt.
+ \item Fixing dependencies. Given the list from step 3 I used a shell cmd: \\
+\begin{flushleft}
+
+for i in `cat /root/all`; do \\
+ echo -n "s:(\$i)[ \t]:\ \$1/";\\
+ echo -n `basename */\$i/[0-9]*`; \\
+ echo " :;" ; \\
+done > ~/edit.pl\\
+\end{flushleft}
+
+ Making the following perl:
+
+\begin{flushleft}
+s:(linc)[ \t]:\$1/1.1.1 :;\\
+s:(libIDL)[ \t]:\$1/0.8.2 :;\\
+s:(ORBit2)[ \t]:\$1/2.8.1 :;\\
+s:(libbonobo)[ \t]:\$1/2.4.0 :;\\
+s:(GConf2)[ \t]:\$1/2.4.0.1 :;\\
+...\\
+\end{flushleft}
+
+\item Once all that was done (several iterations of 1,2 a couple of 3-5) a clean build.
+\end{enumerate}
+
+\subsection{Caveats}
+
+Please remember versioning has 2 (main) intentions:
+
+\begin{enumerate}
+\item Allowing relatively long-term coexistence of (mostly) programming tool versions.
+\item Enabling more orderly transition (and perhaps safer rollback) between versions of the more complex and error-prone modules.
+\end{enumerate}
+
+It's assumed that to switch between versions (at either runtime or buildtime) the user may need to a. modify the PATH (not *always necessary, e.g. *most, not all* applications will build correctly by setting CC=/path/to/my/C/compiler.) \par
+
+Additionally assume the user may need to either set LD\_LIBRARY\_PATH or edit /etc/ld.so.conf and run 'ldconfig' which is more invasive and (for now) requires root privilege. \par
More information about the Lunar-commits
mailing list