diff options
author | Ciaran McCreesh <ciaranm@ciaranm.org> | 2007-01-11 02:00:47 +0000 |
---|---|---|
committer | Ciaran McCreesh <ciaranm@ciaranm.org> | 2007-01-11 02:00:47 +0000 |
commit | ea32fc572c147a934602f29fd7e57c501f7fc48d (patch) | |
tree | 55bdb635765a6182b8ded702f752ae7d0b7976a0 /introduction.tex | |
parent | Add missing end description (diff) | |
download | pms-ea32fc572c147a934602f29fd7e57c501f7fc48d.tar.gz pms-ea32fc572c147a934602f29fd7e57c501f7fc48d.tar.bz2 pms-ea32fc572c147a934602f29fd7e57c501f7fc48d.zip |
Various wording cleanups. Make a bulletlist environment and use that rather than itemize to avoid silly amounts of blank space
git-svn-id: http://svn.repogirl.net/pms/trunk@23 a05a4626-2124-0410-b604-e6c5abf33261
Diffstat (limited to 'introduction.tex')
-rw-r--r-- | introduction.tex | 34 |
1 files changed, 22 insertions, 12 deletions
diff --git a/introduction.tex b/introduction.tex index e061863..80c94b7 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,23 +1,33 @@ \chapter{Introduction} \section{Aims and Motivation} -This document aims to document fully the format of an ebuild repository and the ebuilds therein, as -well as certain aspects of package manager behaviour required to support such a repository. The -reason is simple: at present the only definition of what an ebuild can assume about its environment, -the only definition of what is valid in an ebuild, is the source code of the latest Portage release + +This document aims to fully describe the format of an ebuild repository and the ebuilds therein, as +well as certain aspects of package manager behaviour required to support such a repository. + +This document is \i{not} designed to be an introduction to ebuild development. Prior knowledge of +ebuild creation and an understanding of how the package management system works is assumed; certain +less familiar terms are explained in the Glossary in chapter \ref{glossary}. + +This document does not specify any user or package manager configuration information. + +\section{Rationale} + +At present the only definition of what an ebuild can assume about its environment, +and the only definition of what is valid in an ebuild, is the source code of the latest Portage release and a general consensus about which features are too new to assume availability. This has several drawbacks: not only is it impossible to change any aspect of Portage behaviour without verifying that nothing in the tree relies upon it, but if a new package manager should appear it becomes -impossible to fully support such an ill-defined standard. This document aims to address both of -these concerns by defining almost all aspects of what an ebuild repository looks like, and how an -ebuild is allowed to behave. Thus, both Portage and other package managers can change aspects of -their behaviour not defined here without worry of incompatibilities with any particular repository. +impossible to fully support such an ill-defined standard. + +This document aims to address both of these concerns by defining almost all aspects of what an +ebuild repository looks like, and how an ebuild is allowed to behave. Thus, both Portage and other +package managers can change aspects of their behaviour not defined here without worry of +incompatibilities with any particular repository. \section{Conventions} -Text in \t{teletype} is used for filenames or variable names. \i{Italic} text is used for terms -whose meaning may not be obvious to someone without specific prior knowledge, though a good -knowledge of ebuild development is assumed throughout. Most of these terms are explained in the -Glossary in chapter \ref{glossary}. +Text in \t{teletype} is used for filenames or variable names. \i{Italic} text is used for terms +with a particular technical meaning in places where there may otherwise be ambiguity. % vim: set filetype=tex fileencoding=utf8 et tw=100 spell spelllang=en : |