Sophie

Sophie

distrib > Mandriva > 2007.1 > x86_64 > media > contrib-release > by-pkgid > 3d0d0177db421ffde0b64948d214366a > files > 97

polyxmass-doc-0.9.0-1mdv2007.0.noarch.rpm

\chapter[Installation Overview]{Installation Overview}
\label{chap:installation-overview}

As of release 0.9.6 of the polyxmass-bin package, no libpolyxmass
package is needed anymore.

The \pxm software suite is a multi-modular software framework. It is
made of a number of modular packages that depend on each other. The
installation of the \pxm software suite can be achieved with no pain
by following the instructions in this chapter. 


The dependencies between the modules of the \pxm software framework
are ``ordered'', which means that they require that the modules of the
framework be installed on the same system in an ordered manner.

Modules from the \pxm software suite might be modified independently,
which means that it is not required that they have the same package
version number. For example, a modification in the \filename{\pxmng}
program of the \pxm software suite might not necessarily involve
changes in the \filename{\pxmdatang} package ---that is also part of
the \pxm software suite. Thus, the \pxm program will have an
incremented version number, while the data package itself remains with
a constant version number. The dependencies are dealt with at install
time, so the best way to make a fresh install of the \pxm software
suite is to take all the most recent packages from \pxmurlbase. If
there are no errors (\textit{errare humanum est}) in the dependency
mechanics, all the packages should be installed easily.

Prior to analyzing the installation procedure as a whole, it is
necessary to describe the packaging systems that are available for the
user to install, manage and remove software packages from the system.

\noindent
\begin{center}
  \fbox{\parbox{0.9\textwidth}{Making packages for distributions comes
      at the price of big efforts from the packager. The program is
      always first distributed as a \fileformat{tar.gz} ``tarball''
      where all the sources required to compile the software are
      located. This ``tarball'' packaging is the most natural one for
      the developer, as it is very near to what she has used to
      develop the software. Packagers use these ``tarball'' packages
      to prepare binary packages so that non-geek users can easily
      install precompiled software onto their machine.  Preparing
      binary packages from source is a big work, and packagers do not
      always have the time required to do it in a short delay after
      new releases of the program. Please, be patient and wait for the
      packages to be prepared. If you find that the packages come too
      slowly after software release, learn how to package software and
      prepare the packages yourself.  I'll be happy to offer packages
      that you prepared on my server \pxmurlbase.}}
\end{center}

Delivering software to the users can be performed using a number of
file formats:

\begin{itemize}
\item Uncompiled source package file formats:
  \begin{itemize}
  \item \fileformat{tar.gz} files which need to be compiled using the
    \software{GNU make} program (these are the ``tarball'' archives
    mentioned earlier);
  \item \fileformat{dsc} plus \fileformat{tar.gz} files which need to
    be compiled into a binary installable package using the
    \DebianGNUL packaging system;
  \item \fileformat{src.rpm} files which need to be compiled into a
    binary installable package using the \software{rpm} tool;
  \end{itemize}
\item Binary ready-to-install package file formats:
  \begin{itemize}
  \item \fileformat{\_i386.deb} files that are dependent on the
    computing platform architecture (must be installed using the
    \software{apt-get} or the \software{dpkg} tools in the \DebianGNUL
    distribution);
  \item \fileformat{i386.rpm} files that are dependent on the
    computing platform architecture (must be installed using the
    \software{rpm} tool);
  \item \fileformat{\_all.deb} files that are non-dependent on the
    computing platform architecture (must be installed using the
    \software{apt-get} or the \software{dpkg} tools in the \DebianGNUL
    distribution);
  \item \fileformat{noarch.rpm} files that are non-dependent on the
    computing platform architecture (must be installed using the
    \software{rpm} tool).
  \end{itemize}
\end{itemize}


\renewcommand{\sectitle}{Installing From The \fileformat{tar.gz} Sources}
\section*{\sectitle}
\addcontentsline{toc}{section}{\numberline{}\sectitle}


Installing a package from the source is as easy as issuing the
following commands in the correct order: \\

\begin{mynoindent}
  \prompt\ \command{cp} \filename{\pxmng-\pxmver.tar.gz}
  \filename{/tmp}
  \kbdEnterKey\ {\footnotesize copy the package file into a safe place}\\
  \prompt\ \command{cd} \filename{/tmp} \kbdEnterKey\ \\
  \prompt\ \command{tar} \option{xvzf}
  \filename{\pxmng-\pxmver.tar.gz} \kbdEnterKey\ {\footnotesize this
    unpacks the sources into a source
    tree in the \filename{\pxmng-\pxmver} directory} \\
  \prompt\ \command{cd} \filename{\pxmng-\pxmver} \kbdEnterKey \\
  \prompt\ \command{./configure} \option{---prefix=/usr}
  \option{---sysconfdir=/etc} \kbdEnterKey\ {\footnotesize these are
    the two conventional options used with the \command{./configure}
    command} \\
  \prompt\ \command{make} \kbdEnterKey\ {\footnotesize perform the
    actual compilation of the software} \\
  \prompt\ \command{su} \kbdEnterKey\ {\footnotesize become root if it
    is possible}\\
  \promptsu\ \command{make install} \kbdEnterKey\ {\footnotesize
    finally ask that the successfully compiled software be installed
    to the destination system directories, as required using the
    options to the \command{./configure} command}\\
\end{mynoindent}

As seen in the commands shown above, there are two options that the
user might try when running the \command{configure} script before
building the software:

\begin{itemize}
\item \option{---prefix=/usr}: this option governs the file-system
  tree where the software is to be installed. Binary packages always
  install new software in the file-system rooted at location
  \filename{/usr}. Source packages, like the ones being described
  right now, usually install software in the file-system rooted at
  location \filename{/usr/local}, as it is assumed that such software
  is only for use by the local machine, and does not enter in the
  composition of the default machine setup. It is possible to force
  source packages to install into the \filename{/usr} file-system tree
  by using the option \option{---prefix=/usr};
\item \option{---sysconfdir=/etc}: this options governs the
  installation of the most critical configuration files of the whole
  \pxm software suite. Binary packages set this option to
  \filename{/etc}, which means that all the critical configuration
  files are located in the \filename{/etc/polyxmass} directory. The
  default location for source packages, like the ones described here,
  is also \filename{/etc}.
\end{itemize}

\noindent The only reason why the user (who is installing software and
not merely using it) will want to use/modify the options above, is to
install software without having system administrator priviledges
(\textit{i.e.} without being root). In this case, it is
\emph{essential} that both options be passed identically to the
\command{configure} script of \emph{each package} of the \pxm software
suite. This is because each package of the suite is relying on the
knowledge that all the other packages have been installed in a
determinate file-system tree (\filename{/usr}, \filename{/tmp},
\filename{/opt} or \filename{/home/rusconi}, for example). This is
crucial, otherwise all the software suite's modules cannot speak one
to each other.

As one example, this is what I tried to make sure the software is
---in fact--- \textit{a priori} installation directory-agnostic:

\begin{itemize}
\item I installed the \pxmcommon package by issuing the following
  configuration/installation commands:
  \begin{itemize}
  \item \command{./configure} \option{---prefix=/tmp}
    \option{---sysconfdir=/tmp/etc};
  \item \command{make install} \medskip \\
    At this time the fundamental configuration/data files are located
    in a number of locations all rooted in \filename{/tmp}:
    \filename{/tmp/etc/polyxmass}, \filename{/tmp/share},
    \filename{/tmp/sbin}.
    \end{itemize}
  \item Next, I installed the other packages using always the same
    \command{./configure} \option{---prefix=/tmp}
    \option{---sysconfdir=/tmp/etc} command line.
\end{itemize}

When the operations above were performed successfully I could launch
the \command{\pxmng} program from \filename{/tmp/bin}. Since that
directory is not in the PATH, it is necessary to first change the
working directory to this directory, using \command{cd /tmp/bin}. Next
it is necessary to execute \command{\pxmng} by telling the shell that
the executable is to be found in the current working directory:
\command{./\pxmng}. The program should launch successfully.

\renewcommand{\sectitle}{Installing From The \software{deb} Binary Package}
\section*{\sectitle}
\addcontentsline{toc}{section}{\numberline{}\sectitle}


\label{sect:inst-from-bin-deb} 

On the \DebianGNUL distribution, the packaging system makes the
installation of software incredibly easy. The \software{apt-get}
package manager is particularly clever in determining the dependencies
between packages in an inter-related array of two or more packages.
The \software{apt-get} package manager needs to connect to some place
over the network and download a file from that place (which is called
a software repository) that will tell what packages are available at
that specific place and how they inter-relate. Since the adoption of
\pxm as an official \DebianGNUL distribution package, installing the
software is a easy as issuing the following command lines as root:

\begin{mynoindent}
  \promptsu\ \command{apt-get} \option{update} \kbdEnterKey\\
  \promptsu\ \command{apt-get} \option{install} \filename{\pxmng}
  \kbdEnterKey\\
\end{mynoindent}

\noindent and something like the following will be output to your
terminal:

\begin{alltt}
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  polyxmass-bin polyxmass-bin-common polyxmass-common polyxmass-data
The following NEW packages will be installed:
  polyxmass-bin polyxmass-bin-common polyxmass-common polyxmass polyxmass-data
0 upgraded, 3 newly installed, 0 to remove and 9 not upgraded.
Need to get 5020kB of archives.
After unpacking 8577kB of additional disk space will be used.
Do you want to continue? [Y/n]
\end{alltt}

\noindent All this output to install one package? ---``What is it
going on?,'' you may ask. Well, that's the power of the system:
\software{apt-get} has detected that in order to install the \pxmng
package, it is necessary to first install packages onto which \pxmng
actually depends.  These packages are listed:

\begin{alltt}
  The following extra packages will be installed:
  polyxmass-bin polyxmass-bin-common polyxmass-common polyxmass-data
\end{alltt}

\noindent Which means that, in total, with the initially requested
package,

\begin{alltt}
The following NEW packages will be installed:
  polyxmass-bin polyxmass-bin-common polyxmass-common polyxmass-data polyxmass
0 upgraded, 5 newly installed, 0 to remove and 9 not upgraded.
\end{alltt}

\noindent If you accept to continue (key-in \kbdKey{Y} \kbdEnterKey),
this is what you get: all the packages get automatically downloaded,
installed and configured. That's the \DebianGNUL packaging system
magic: there is no higher standard for such package managing tasks
nowadays.

To see all the files that are provided by a given \DebianGNUL
package file, issue the following command:\\

\begin{mynoindent}
  \prompt\ \command{dpkg} \option{-c}
  \filename{\pxmng-bin\pxmver-1.i386.deb} \kbdEnterKey\\
\end{mynoindent}

The output of this command is a list of all the files ---along with
their destination directories--- that would be installed if the
package were installed as above.



\renewcommand{\sectitle}{Installing From The \software{rpm} Binary Package}
\section*{\sectitle}
\addcontentsline{toc}{section}{\numberline{}\sectitle}

\label{sect:inst-from-bin-rpm} 


Installing any \fileformat{rpm} package using the \software{rpm}
program\footnote{For an in-depth manual on the \software{rpm} packet
  manager, you might want to read \emph{Maximum RPM}, a book by Ed
  Bailey, available from \url{http://www.rpm.org}.} is as easy as
entering the following commands, as root:\\

\begin{mynoindent}
  \promptsu\ \command{rpm} \option{-ivh}
  \filename{\pxmcommonng-\pxmcommonver-1.i386.rpm} \kbdEnterKey\\
  \promptsu\ \emph{optionally} \command{rpm} \option{-ivh}
  \filename{\pxmdatang-\pxmdataver-1.i386.rpm}
  \kbdEnterKey\\
  \promptsu\ \command{rpm} \option{-ivh}
  \filename{\pxmbinng-\pxmver-1.i386.rpm} \kbdEnterKey\\
\end{mynoindent}

\noindent What these commands do is to read the contents in each of
the packages (these package files do contain a number of files packed
in them) and copy them to their destination directories.  The
\fileformat{rpm} file format lets the packager define where each of
the files contained in a package has to be installed. To see all the
files that are provided by a given \software{rpm}-based
package file, issue the following command:\\

\begin{mynoindent}
  \prompt\ \command{rpm} \option{-qpl}
  \filename{\pxmbinng-\pxmver-1.i386.rpm} \kbdEnterKey\\ 
\end{mynoindent}

The output of this command is a list of all the files ---along with
their destination directories--- that would be installed if the
package were installed as above.


\renewcommand{\sectitle}{Installation On A \OSname{Mac~OS~X} System With \software{Fink}}
\section*{\sectitle}
\addcontentsline{toc}{section}{\numberline{}\sectitle}

\label{sect:ins-macosx-fink}

The \OSname{Mac~OS-X} operating system can run \corpname{GNU} software
when the \software{Fink} porting system is installed (please, visit
\url{http://fink.sourceforge.net} for details on this project). The
notes below were kindly provided to me by D$\mathrm{^r}$ Mark Tracy.
If you find errors, they are mine, and I am the only one to be blamed
for badly transcribing these notes.

\bigskip\pxm was successfully installed on the Mac OS-X/Fink platform.
For example, version 0.8.6 of the modules of the \pxm software suite
could be installed using the info files maintained by D$\mathrm{^r}$
Mark Tracy.  These \software{Fink} \fileformat{info} files are scripts
much like the \software{rpm} \fileformat{spec} files. Using the
scripts, \software{Fink} will download the source tarballs, apply any
patches, install dependent packages, compile the code and install the
finished files.  The \software{Fink} packaging system relies on the
usual \fileformat{tar.gz} source files, which may be used without
modification.  However, the case may arise that the \OSname{Mac
  OS-X/Fink} platform requires that the package maintainer changes the
code of the source tree for one or more packages in the \pxm suite. In
this case, the patch files would be distributed along with the source
tarball files and the \fileformat{info} files.  The \fileformat{info}
script will automatically apply the patches, and complain should you
forget them.  Providing patch files for the software to build
correctly on any given platform is the task of the packager.  Once you
have downloaded all the required files (\fileformat{info},
\fileformat{patch}), the installation process is as easy as doing the
following: If you obtained the scripts from the \software{Fink}
server, \software{Fink} will automatically install them in the right
place and you skip the copying step. The \software{Fink} service tends
to lag behind the latest version due to their diligent review process.
If you obtained the scripts from \url{http://www.polyxmass.org}, you
need to copy them to the right place:  \\

\begin{mynoindent}
  \prompt\ \command{sudo cp *.info /sw/fink/10.3/local/main/finkinfo}\kbdEnterKey\ \\
  \prompt\ \command{sudo cp *.patch /sw/fink/10.3/local/main/finkinfo}\kbdEnterKey\ \\
\end{mynoindent}

Sudo will want your password.  Now comes the time to install the
packages by issuing the following commands:

\begin{mynoindent}
  \prompt\ \command{fink install polyxmass}\kbdEnterKey\ \\
  \prompt\ \command{fink install polyxmass-common}\kbdEnterKey\  (optional)\\
  \prompt\ \command{fink install polyxmass-doc}\kbdEnterKey\  (optional)\\
  \prompt\ \command{fink install polyxmass-examples}\kbdEnterKey\  (optional)\\
\end{mynoindent}

At the behest of the \software{Fink} team, the packages are named
somewhat differently under \software{Fink}. If the software packager
did everything right, \software{Fink} will calculate the dependencies,
and ask you if you want to install the dependent packages (say
yes).\footnote{If this is your first time installing, there will be a
  startling number of dependent files.}  \software{Fink} will begin
downloading the source tarballs.  Note that \pxm is dependent on
several libraries found in the unstable branch of the 10.3 package
tree, therefore \software{Fink} must be so configured (sorry, 10.2 is
no longer supported). When all is finished, open a new X-terminal
window to run the software (yes, it has to be new and it has to be X).


\renewcommand{\sectitle}{Summary}
\section*{\sectitle}
\addcontentsline{toc}{section}{\numberline{}\sectitle}

\label{sect:ins-summary}



We have reviewed a number of ways the \pxm software suite might be
installed on a variety of platforms. The next chapters will deal with
each module separately. 

As a final reminder, before the user picks the best installation
method and does that installation, I would tell that the software
packages in the \pxm software suite should be installed in the
following order:

\begin{enumerate}
\item \filename{polyxmass-common}
\item \filename{polyxmass-bin-common} (or no such package, depending on
  the distribution)
\item \filename{polyxmass-bin} (or \filename{polyxmass}, depending on
  the distribution)
\item \emph{optionally} \filename{polyxmass-data}
\item \emph{optionally} \filename{polyxmass-doc}
\end{enumerate}

The following chapters will describe the software suite with all the
details that are required so that the user gets an intimate knowledge
of the way the whole integrated \pxm mass spectrometric software suite
works.


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "polyxmass"
%%% End: