[Cdd-commits] r949 - cdd/trunk/cdd/doc/en
CDD Subversion Commit
noreply at alioth.debian.org
Wed Jul 9 05:25:10 UTC 2008
Author: tille
Date: Wed Jul 9 05:25:10 2008
New Revision: 949
Modified:
cdd/trunk/cdd/doc/en/00_titletoc.sgml
cdd/trunk/cdd/doc/en/04_existing_cdds.sgml
cdd/trunk/cdd/doc/en/06_technology.sgml
cdd/trunk/cdd/doc/en/07_starting.sgml
cdd/trunk/cdd/doc/en/08_websentinel.sgml
cdd/trunk/cdd/doc/en/09_todo.sgml
cdd/trunk/cdd/doc/en/A_devel.sgml
cdd/trunk/cdd/doc/en/B_quickintro.sgml
cdd/trunk/cdd/doc/en/C_bts.sgml
Log:
spelling: s/Chemestry/Chemistry/; s/meta.package/metapackage/
Modified: cdd/trunk/cdd/doc/en/00_titletoc.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/00_titletoc.sgml (original)
+++ cdd/trunk/cdd/doc/en/00_titletoc.sgml Wed Jul 9 05:25:10 2008
@@ -17,7 +17,7 @@
It is explained in detail why these are not forks from Debian, but reside
completely inside the Debian GNU/Linux distribution, and which
advantages can be enjoyed by taking this approach. The concept of
-meta-packages and user role based menus is explained. In short: This
+metapackages and user role based menus is explained. In short: This
document describes why Custom Debian Distributions are important to
the vitality and quality of Debian.
</abstract>
Modified: cdd/trunk/cdd/doc/en/04_existing_cdds.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/04_existing_cdds.sgml (original)
+++ cdd/trunk/cdd/doc/en/04_existing_cdds.sgml Wed Jul 9 05:25:10 2008
@@ -190,7 +190,7 @@
DeMuDi site was no help, as I couldn't find goals for the project listed
there. Perhaps the point should just be stricken?
[AT] I just wanted to express the fact that I got the word
- that the first meta-packages are in preparation by Free Enkanayaka.
+ that the first metapackages are in preparation by Free Enkanayaka.
-->
<item>Oriented toward music and multimedia.</item>
<item>To make GNU/Linux a platform of choice for the musician
@@ -222,7 +222,7 @@
</sect>
<sect id="debichem">
- <heading>DebiChem: Debian for Chemestry</heading>
+ <heading>DebiChem: Debian for Chemistry</heading>
<p>
<taglist>
@@ -260,7 +260,7 @@
<p>
While there are Custom Debian Distributions that care for certain
sciences (Debian-Med deals in a main part with Biology, DebiChem for
- Chemestry and Debian-GIS for geography) not all sciences are covered
+ Chemistry and Debian-GIS for geography) not all sciences are covered
by a specific CDD. The main reason is that at the moment not enough
people support such an effort for every science. The temporary
solution was to build a general Debian-Science CDD that makes use of
Modified: cdd/trunk/cdd/doc/en/06_technology.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/06_technology.sgml (original)
+++ cdd/trunk/cdd/doc/en/06_technology.sgml Wed Jul 9 05:25:10 2008
@@ -2,13 +2,13 @@
<heading>Technology</heading>
<sect id="metapackages">
- <heading>Meta packages</heading>
+ <heading>Metapackages</heading>
<sect1 id="defmetapackages">
- <heading>Meta package definition</heading>
+ <heading>Metapackage definition</heading>
<p>
-A meta package, as used by CDDs, is a Debian package that contains:
+A metapackage, as used by CDDs, is a Debian package that contains:
<list>
<item>Dependencies on other Debian packages (essential)
<taglist>
@@ -19,7 +19,7 @@
<tag>Recommends</tag>
<item>The packages that are listed as "Recommends" in the
tasks file should be installed on the machine where the
- meta package is installed and which are needed to work
+ metapackage is installed and which are needed to work
on a specific task.
</item>
<tag>Suggests</tag>
@@ -27,7 +27,7 @@
package to specify "Enhances" to avoid this problem?
[AT] I have to admit that "Enhances" is new to me. When
reading policy I think this field is out of control of
- the meta-package developer because it has to be included
+ the metapackage developer because it has to be included
by the package maintainer. I'm not really convinced that
this is a good solution - but I would follow the suggestions
of others in this issue.
@@ -35,9 +35,9 @@
<item>Use "Suggests" for others of lesser importance that
might be possibly useful, or non-free packages. When a
package is not available for the target distribution at
- meta package build time the "Recommends" is turned into
+ metapackage build time the "Recommends" is turned into
a "Suggests" to enable a flawless installation of the
- meta package.
+ metapackage.
</item>
</taglist>
</item>
@@ -53,7 +53,7 @@
<item><prgn>cfengine</prgn> scripts (or similar see <ref id="EnhancingTechnology">)</item>
</list>
</item>
- <item>Special meta packages:
+ <item>Special metapackages:
<list>
<item><package><var><cdd></var>-tasks</package>:
Contains information for <prgn>tasksel</prgn></item>
@@ -64,9 +64,9 @@
</list>
</p>
<p>
-Meta packages are small packages with nearly no contents. The main
+Metapackages are small packages with nearly no contents. The main
feature of this type of package is its dependencies on other
-packages. The naming of meta packages follows the pattern
+packages. The naming of metapackages follows the pattern
<var><cdd></var>-<var><task></var> where <var><cdd></var> stands for the
short name of a Custom Debian Distribution,
e.g. <package>junior</package> for Debian Jr. or <package>med</package>
@@ -90,42 +90,42 @@
<heading>Collection of specific software</heading>
<p>
-When using meta packages, no research for available software inside Debian is
+When using metapackages, no research for available software inside Debian is
necessary. It would not be acceptable for normal users to have to browse the
descriptions of the whole list of the 10000 packages in Debian to find
-everything they need. So, meta packages are an easy method to help users to
+everything they need. So, metapackages are an easy method to help users to
find the packages that are interesting for their work quickly.
</p>
<p>
-If the author of a meta package includes several packages with similar
+If the author of a metapackage includes several packages with similar
functionality, an easy comparison between software covering the same task is
possible.
</p>
<p>
-Moreover, the installation of a meta package ensures that no package
+Moreover, the installation of a metapackage ensures that no package
that is necessary for the intended task can be removed without
-explicit notice that also the meta package has to be removed. This
+explicit notice that also the metapackage has to be removed. This
helps non specialist administrators to keep the installation fit for
the specialized users.
</p>
<p>
-By defining conflicts with some other packages inside the meta package,
+By defining conflicts with some other packages inside the metapackage,
it is possible to ensure that a package that might conflict for some
reasons for the intended task can not be installed at the same time as
-the meta package is installed.
+the metapackage is installed.
</p>
<p>
-All in all, meta packages enable an easy installation from scratch, and
+All in all, metapackages enable an easy installation from scratch, and
keep the effort required for administration low.
</p>
</sect1>
<sect1 id="configuration">
- <heading>Adapted configuration inside meta packages</heading>
+ <heading>Adapted configuration inside metapackages</heading>
<p>
Besides the simplification of installing relevant packages by
-dependencies inside meta packages, these packages might contain special
+dependencies inside metapackages, these packages might contain special
configuration for the intended task. This might either be
accomplished by pre-seeding <prgn>debconf</prgn> questions, or by
modifying configuration files in a <prgn>postinst</prgn> script. It
@@ -170,20 +170,20 @@
</sect>
<sect id="mp_handling">
- <heading>Handling of meta packages</heading>
+ <heading>Handling of metapackages</heading>
<p>
<!-- [BA] I think we need to qualify what 'handle' means, because there
certainly are other tools that 'handle' them (e.g. synaptic) if that term
is taken in its broadest sense.
[AT] ACK, here that we have to define 'handle'. The term
- 'nicely' was intended to be the keyword because meta-packages are
+ 'nicely' was intended to be the keyword because metapackages are
currently handled as any other package which is fine, but no help
- for users who do not know anything about meta-packages. We need
+ for users who do not know anything about metapackages. We need
special tools to gain all profits we could have. Could you set
this into good English???
-->
-In short, there are no special tools available to handle meta packages
+In short, there are no special tools available to handle metapackages
nicely. But there are some tricks that might help, for the moment.
</p>
@@ -325,7 +325,7 @@
</taglist>
The short conclusion here is: <strong>There are no sophisticated tools
-that might be helpful to handle meta packages as they are used in Custom
+that might be helpful to handle metapackages as they are used in Custom
Debian Distributions - just some hacks using the powerful tools inside
Debian.</strong>
</p>
@@ -339,7 +339,7 @@
<tag><prgn>dselect</prgn></tag>
<item>
This good old package handling tool provides no special help to
- handle meta packages in an elegant manner.
+ handle metapackages in an elegant manner.
</item>
<tag><prgn>tasksel</prgn></tag>
<item>
@@ -392,10 +392,10 @@
useful support for searching for and grouping of packages. While
this is not bad, it was not intended for the purpose of handling
Custom Debian Distributions, and thus there could be some better support
- to handle meta packages more cleverly.
+ to handle metapackages more cleverly.
</item>
</taglist>
-Short conclusion: <strong>There is a good chance meta packages could be
+Short conclusion: <strong>There is a good chance metapackages could be
handled nicely by the text based Debian package administration tools,
but this is not yet implemented.</strong>
</p>
@@ -417,7 +417,7 @@
instance the packages of the Debian Jr. project come into the
focus of interest a search for "<tt>junior-*</tt>" will show
up all related packages including their descriptions. This
- will give a reasonable overview about meta packages of the
+ will give a reasonable overview about metapackages of the
project.
</item>
<tag><prgn>synaptic</prgn></tag>
@@ -465,7 +465,7 @@
provides essential information about packages. Regarding
Custom Debian Distributions it can help if you know the
Debian user name of the developer who is responsible for the
- meta packages:
+ metapackages:
<taglist>
<tag>Debian-Jr:</tag>
<item>
@@ -479,7 +479,7 @@
<item>
<url id="http://qa.debian.org/developer.php?login=pere">
</item>
-<!-- currently no meta packages released for this project ...
+<!-- currently no metapackages released for this project ...
<tag>Debian-NP:</tag>
<item>
<url id="http://qa.debian.org/developer.php?login=mako">
@@ -524,7 +524,7 @@
</sect1>
<sect1 id="future_handling">
- <heading>Future handling of meta packages</heading>
+ <heading>Future handling of metapackages</heading>
<p>
Obviously there are no nifty tools as you might know them from Debian
@@ -535,12 +535,12 @@
reasonable functionality. The following items are target of future
development:
<list>
- <item>Searching for existing meta packages</item>
- <item>Overview about dependencies of these meta packages</item>
+ <item>Searching for existing metapackages</item>
+ <item>Overview about dependencies of these metapackages</item>
<item>Enhancing tools like <prgn>aptitude</prgn>,
<prgn>synaptic</prgn>, etc.</item>
<item>Special <prgn>tasksel</prgn> section</item>
- <item>Web tools that keep meta package information up to
+ <item>Web tools that keep metapackage information up to
date</item>
</list>
</p>
@@ -551,7 +551,7 @@
Debian Package Tags, which is a quite promising technique.
</p>
<p>
-Tools that grep the apt cache directly for meta packages have to be
+Tools that grep the apt cache directly for metapackages have to be
written or rather the available tools for this should be patched for
this actual functionality.
</p>
@@ -633,7 +633,7 @@
user. To accomplish this a call of the general
<prgn>update-menu</prgn> script for every single user of a Custom
Debian Distribution is necessary if this is not done by the
-<file>postinst</file> script of a meta package. This can easily been
+<file>postinst</file> script of a metapackage. This can easily been
done if the configuration file of a Custom Debian Distribution
<file>/etc/cdd/<var><cdd></var>/<var><cdd></var>.conf</file> contains the
line
@@ -644,7 +644,7 @@
</p>
<p>
It is strongly suggested to use the package <package>cdd-dev</package>
-to build meta packages of a Custom Debian Distribution that will move
+to build metapackages of a Custom Debian Distribution that will move
all necessary files right into place if there exists a
<file>menu</file> directory with the menu entries. Note, that the users
<file>${HOME}/.menu</file> directory remains untouched.
@@ -697,16 +697,16 @@
<heading>Development tools</heading>
<p>
-Building a meta package is more or less equal for each meta
+Building a metapackage is more or less equal for each meta
package. This was the reason to build a common source package
<package>cdd</package> that builds into two binary packages
<taglist>
<tag><package>cdd-dev</package></tag>
- <item><p>Helpful tools to build meta packages from a set of template
+ <item><p>Helpful tools to build metapackages from a set of template
files. These tools are interesting for people who want to
- build meta packages in the style Debian-Edu and Debian-Med
+ build metapackages in the style Debian-Edu and Debian-Med
are currently doing this. The purpose of this package is to
- make maintenance of meta packages as easy as possible.</p>
+ make maintenance of metapackages as easy as possible.</p>
<p>This package is described in detail in appendix <ref
id="cdd-dev">.</p>
</item>
Modified: cdd/trunk/cdd/doc/en/07_starting.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/07_starting.sgml (original)
+++ cdd/trunk/cdd/doc/en/07_starting.sgml Wed Jul 9 05:25:10 2008
@@ -320,11 +320,11 @@
</sect1>
<sect1 id="tasksel">
- <heading>Using tasksel and meta packages</heading>
+ <heading>Using tasksel and metapackages</heading>
<p>
- According to the plan of the project, the first meta packages (<ref
+ According to the plan of the project, the first metapackages (<ref
id="metapackages">) should be developed. It is not always easy to
- decide what should be included, and which meta packages should be
+ decide what should be included, and which metapackages should be
built. The best way to decide on this point is to discuss on the
mailing list some well thought out proposals.
</p>
Modified: cdd/trunk/cdd/doc/en/08_websentinel.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/08_websentinel.sgml (original)
+++ cdd/trunk/cdd/doc/en/08_websentinel.sgml Wed Jul 9 05:25:10 2008
@@ -45,7 +45,7 @@
<item>Even if there is no Debian package available for the moment
the names of prospective packages are given as if they would
exists. The rationale behind is that once such a package
- might exist the source of the meta package does not have to
+ might exist the source of the metapackage does not have to
be changed and will work out of the box after rebuilding.
</item>
<tag>Ignore</tag>
@@ -54,7 +54,7 @@
evaluated once it appears in the Debian package pool. If
"Depends", "Recommends" or "Suggests" are used for not yet
existing packages they will be turned into the list of Suggests
- of the meta package and thus might be possible to become
+ of the metapackage and thus might be possible to become
installed on a users machine if the user decides to install all
suggested packages. If some evaluation should be done first the
"Ignore" tag is your friend.
Modified: cdd/trunk/cdd/doc/en/09_todo.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/09_todo.sgml (original)
+++ cdd/trunk/cdd/doc/en/09_todo.sgml Wed Jul 9 05:25:10 2008
@@ -9,7 +9,7 @@
of specific development issues. Because there are several common
issues between all Custom Debian Distributions also a common mailing
list was created. People who are interested in working on common
-issues like building meta packages, technical issues of menu systems
+issues like building metapackages, technical issues of menu systems
or how to create CDs for Custom Debian Distributions could <url
id="http://lists.debian.org/debian-custom/" name="subscribe to this
list or read the list archive">.
@@ -237,7 +237,7 @@
<taglist>
<tag>available Debian package</tag>
<item>Top most you should list all packages which are just inside
- Debian and thus (hopefully) included in the meta package
+ Debian and thus (hopefully) included in the metapackage
dependencies. This should be followed by the projects which
has unofficial packages outside Debian. A last group should
list all not yet packaged projects which are interesting for
@@ -255,7 +255,7 @@
</p>
</sect1>
<sect1 id="graphingwebpages">
- <heading>Automatically graphing the meta-package dependencies for web
+ <heading>Automatically graphing the metapackage dependencies for web
pages</heading>
<p>
The new <package>cddtk</package> contains a tool which allows browsing
@@ -332,16 +332,16 @@
<p>
In section <ref id="future_handling"> several issues where raised how
-handling of meta packages should be enhanced.
+handling of metapackages should be enhanced.
</p>
<p>
-Regarding to building meta packages for all Custom Debian
+Regarding to building metapackages for all Custom Debian
Distributions consistently it might make sense to use the following
approach:
</p>
<!-- FIXME: How to indent a paragraph??? -->
<p>
- The method how Debian-Edu currently builds its meta packages from a
+ The method how Debian-Edu currently builds its metapackages from a
kind of <em>database</em> (in the <file>tasks</file> directory of the source)
was generalised in the packages <package>cdd-dev</package> (<ref
id="cdd-dev">) and <package>cdd-common</package> (<ref
@@ -350,7 +350,7 @@
It might be a good idea to maintain a more general kind of database
than this <file>tasks</file> directory approach currently represents
for each Custom Debian Distribution. From
- this database the control files for all meta packages could be
+ this database the control files for all metapackages could be
built on demand to build the necessary files of the
<file>debian</file> directory in the package build process
dynamically. The extra plus would be that it would be easy to
@@ -358,7 +358,7 @@
dynamically. It would drastically reduce the amount of work for
keeping the project related web sites up to date if this could be
done automatically. Some tools like the following might be easily
- done to support maintenance and documentation of the meta packages:
+ done to support maintenance and documentation of the metapackages:
<example>
build_cdd-package med bio
build_cdd-package junior toys
@@ -375,16 +375,16 @@
</p>
<p>
Last but not least the special configuration issue has to be
-addressed. In general developers of meta packages should provide
+addressed. In general developers of metapackages should provide
patches for dependent packages if they need a certain configuration
option and the package in question does feature a
<prgn>debconf</prgn> configuration for this case. Then the
-meta package could provide the needed options by pre-seeding the
+metapackage could provide the needed options by pre-seeding the
<prgn>debconf</prgn> database while using very low priority questions
which do not came to users notice.
</p>
<p>
-If the maintainer of a package which is listed in a meta package
+If the maintainer of a package which is listed in a metapackage
dependency and needs some specific configuration does not accept such
kind of patch it would be possible to go with a <prgn>cfengine</prgn>
script which just does the configuration work. According to the
@@ -402,7 +402,7 @@
questions or even to adapt local configuration for Custom Debian
Distribution use in general - a common location for this kind of stuff
should be found. Because these scripts are not configuration itself
-but substantial part of a meta package the suggestion would be to
+but substantial part of a metapackage the suggestion would be to
store this stuff under
<example>
/usr/share/cdd/#CDD#/#METAPACKAGE#/cf.#SOMETHING#
@@ -578,7 +578,7 @@
package pool system is the fact that some interested groups, who
provide special service for a certain Custom Debian Distribution,
would take over support only for the subset of packages which is
-included in the meta package dependencies or suggestions but they
+included in the metapackage dependencies or suggestions but they
refuse to provide full support for the whole range of Debian
packages. This would lead to a new layout of the file structures of
the Debian mirrors:
Modified: cdd/trunk/cdd/doc/en/A_devel.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/A_devel.sgml (original)
+++ cdd/trunk/cdd/doc/en/A_devel.sgml Wed Jul 9 05:25:10 2008
@@ -4,11 +4,11 @@
<heading>Package <package>cdd-dev</package></heading>
<p>
-If meta packages are builded using the tools inside the
+If metapackages are builded using the tools inside the
<package>cdd-dev</package> package it can be ensured that the
-resulting meta packages will work nicely with the same version of
+resulting metapackages will work nicely with the same version of
<package>cdd-common</package> package. The goal is to keep necessary
-changes for the source of the meta packages of a Custom Debian
+changes for the source of the metapackages of a Custom Debian
Distribution as low as possible when the version of the
<package>cdd</package> source package changes. Thus it is
strongly recommended to use the tools described below.
@@ -17,7 +17,7 @@
The usage of the tools in the <package>cdd-dev</package> package might
introduce a versioned dependency in the
<package><var><cdd></var>-common</package> package from which
-all other meta packages of the <var>CDD</var> in question will
+all other metapackages of the <var>CDD</var> in question will
depend. This <package><var><cdd></var>-common</package> package
instantiates the <var>CDD</var> in the common registry for all CDDs in
<file>/etc/cdd</file>.
@@ -55,7 +55,7 @@
<heading><tt>debian/control</tt></heading>
<p>
-The <file>debian/control</file> file of a CDD meta package source
+The <file>debian/control</file> file of a CDD metapackage source
archive is auto generated out of dependencies that are specified in so
called <file>tasks</file> files. The rationale behind this is to
enhance flexibility about changes inside the Debian package pool where
@@ -67,9 +67,9 @@
the <file>debian/control</file> file according to the available
packages. This does not only work for the Debian package pool
containing the distributions stable, testing and unstable. You can
-even build your meta packages against a different package pool of a
+even build your metapackages against a different package pool of a
Debian based distribution. This is for instance used to create the
-SkoleLinux meta packages.
+SkoleLinux metapackages.
</p>
<p>
The syntax of the <file>tasks</file> files which serve as the central
@@ -85,16 +85,16 @@
<item>Will be turned to "Recommends" in the
resulting <file>debian/control</file> file. The
rationale behind this is to enable installing the
- meta-package even if a package belonging to this task is
+ metapackage even if a package belonging to this task is
missing for whatever reason. It also allows finally to
- remove the meta package. This makes even more
+ remove the metapackage. This makes even more
sense since <prgn>apt-get</prgn> considers "Recommends"
as default installation targets.
</item>
<tag>Recommends</tag>
<item>The packages that are listed as "Recommends" in the
tasks file should be installed on the machine where the
- meta package is installed and which are needed to work
+ metapackage is installed and which are needed to work
on a specific task.
</item>
<tag>Suggests</tag>
@@ -102,7 +102,7 @@
package to specify "Enhances" to avoid this problem?
[AT] I have to admit that "Enhances" is new to me. When
reading policy I think this field is out of control of
- the meta-package developer because it has to be included
+ the metapackage developer because it has to be included
by the package maintainer. I'm not really convinced that
this is a good solution - but I would follow the suggestions
of others in this issue.
@@ -115,12 +115,12 @@
the <file>debian/control</file> file inside the meta
package source archive any "Depends" or "Recommends" are
turned into "Suggests" to enable a flawless installation
- of the meta package. Packages that are specified with
+ of the metapackage. Packages that are specified with
"Suggests" will not be taken over to
the <prgn>tasksel</prgn> control file
(CDD<file>-tasks.desk</file>,
see <ref id="cdd-tasks.desc">) but only to the list of
- suggested packages of the according meta package.
+ suggested packages of the according metapackage.
</item>
<tag>Ignore</tag>
<item>The "Ignore" key can be used as kind of "Soft-Suggests"
@@ -128,7 +128,7 @@
are tagged with Ignore will not be taken over into the
list of dependencies inside
the <file>debian/control</file> file of the resulting
- meta package neither to the CDD<file>-tasks.desk</file>
+ metapackage neither to the CDD<file>-tasks.desk</file>
control file for <prgn>tasksel</prgn> but will be taken
over onto the installation medium of a CDD in case there
is some space left. This key becomes especially
@@ -157,7 +157,7 @@
<tag>NAME</tag>
<item>
<prgn>cdd-clean-helper</prgn> - cleans up debian directory in a
- meta package building tree
+ metapackage building tree
</item>
<tag>SYNOPSIS</tag>
<item>
@@ -275,7 +275,7 @@
<taglist>
<tag>NAME</tag>
<item>
- <prgn>cdd-update-menus</prgn> - add menu of meta package to all Custom Debian Distribution users
+ <prgn>cdd-update-menus</prgn> - add menu of metapackage to all Custom Debian Distribution users
</item>
<tag>SYNOPSIS</tag>
<item>
Modified: cdd/trunk/cdd/doc/en/B_quickintro.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/B_quickintro.sgml (original)
+++ cdd/trunk/cdd/doc/en/B_quickintro.sgml Wed Jul 9 05:25:10 2008
@@ -1,5 +1,5 @@
<appendix id="QuickIntro">
- <heading>Quick intro into building meta packages</heading>
+ <heading>Quick intro into building metapackages</heading>
<p>
There are several descriptions available how to build Debian packages
@@ -17,12 +17,12 @@
</p>
<sect id="Dependencies">
- <heading>Defining dependencies for meta packages</heading>
+ <heading>Defining dependencies for metapackages</heading>
<p>
-This howto describes the building of meta packages by using the
+This howto describes the building of metapackages by using the
<package>cdd-dev</package> package. It is perfectly possible to build
-a meta package as any other normal Debian package but this HOWTO
+a metapackage as any other normal Debian package but this HOWTO
has the only purpose to describe the profit you might gain by using
these tools.
@@ -36,7 +36,7 @@
Depends: <var>dependency1, dependency2, ...</var>
</example>
-For each meta package this skeleton of a <file>debian/control</file>
+For each metapackage this skeleton of a <file>debian/control</file>
entry is needed. All necessary information is available in the
directory <file>/usr/share/doc/cdd-dev/examples/tasks</file>.
</p>
@@ -89,7 +89,7 @@
~> make dist
</example>
to build the source tarball. This tarball has to be moved to a location
-where the meta packages will be built.
+where the metapackages will be built.
Unpack the tarball there and start the build process
using for instance
<example>
@@ -97,7 +97,7 @@
</example>
</p>
<p>
-That's all for the very simple case when the meta packages should not
+That's all for the very simple case when the metapackages should not
contain user menus. Even if user menus are suggested they are not
necessary. The following paragraphs describe how to use the
<package>cdd-dev</package> tools to support these menus.
@@ -105,8 +105,8 @@
</sect>
- <sect id="common-meta-package">
- <heading>The common meta package</heading>
+ <sect id="common-metapackage">
+ <heading>The common metapackage</heading>
<p>
The creation of a common package is optional, but suggested, because it
@@ -127,22 +127,22 @@
general configuration inside the <package>cdd-common</package>.
</p>
<p>
-If the meta package <package><var>cdd</var>-common</package> will be
-created according to these rules all other meta packages will depend
+If the metapackage <package><var>cdd</var>-common</package> will be
+created according to these rules all other metapackages will depend
automatically from this common package. For the friends of
<prgn>auto-apt</prgn>, a helper
-<file>/usr/bin/<var><meta-package-name></var></file> will be
+<file>/usr/bin/<var><metapackage-name></var></file> will be
installed as well, which just prints some information about the meta
package. All in all, the usage of the common package is strongly
suggested to have a common registry for stuff like user roles and
possibly other things that will be implementd in the future.
</p>
</sect>
- <sect id="meta-package-menus">
- <heading>The meta package menus</heading>
+ <sect id="metapackage-menus">
+ <heading>The metapackage menus</heading>
<p>
-As explained in <ref id="menu_tools"> the meta packages can contain
+As explained in <ref id="menu_tools"> the metapackages can contain
user menus. This optional feature can be implemented easily by using
the template from the <package>cdd-dev</package> in the following way:
@@ -151,14 +151,14 @@
~> cat menu/README
~> edit menu/task1
<var>Edit the example to legal menu entries of the
- dependencies of this meta package</var>
-~> cp menu/task1 menu/<var><meta package name></var>
+ dependencies of this metapackage</var>
+~> cp menu/task1 menu/<var><metapackage name></var>
</example>
A menu file for each task should be created containing valid menu
entries for each dependant package. The easiest way to obtain those
menu entries is to simply copy the original menu entry files that are
-contained in the packages on which the meta package will depend.
+contained in the packages on which the metapackage will depend.
The only thing that has to be changed in these menu entries is the
<tt>package</tt> field, which has to be changed from
<package><dependent package></package> to
@@ -166,16 +166,16 @@
might remain unchanged. This is a good point to check whether the
menu entries of the packages you depend from are formated nicely and
print the necessary information (for instance make use of "hints").
-Here the meta package maintainer has a good chance for quality
+Here the metapackage maintainer has a good chance for quality
assurance work, which is also part of the Custom Debian Distributions
issue.
</p>
<p>
In principle these menu items could be created automatically either at
-meta package build time or even better in the <file>postinst</file>
-script of the meta package because it is granted that the needed menu
+metapackage build time or even better in the <file>postinst</file>
+script of the metapackage because it is granted that the needed menu
files are installed on the system, which is not really necessary on
-the meta package build machine. This might be implemented in later
+the metapackage build machine. This might be implemented in later
versions of <package>cdd-dev</package>. Currently the policy is that
we like to have a little bit of control about the menu entries for the
quality assurance issue mentioned above. Last, but not least, there are
@@ -192,11 +192,11 @@
<heading>Menu for any dependency</heading>
<p>
-The idea of the meta package menu is to provide the user with easily
+The idea of the metapackage menu is to provide the user with easily
viewable traces of any installed package that helps solving everyday
tasks. So if there are packages that do not contain a menu, a screen
with relevant documentation should be provided in a viewer by the
-creator of the meta package. Such documentation can be created using
+creator of the metapackage. Such documentation can be created using
the following templates:
<example>
@@ -204,10 +204,10 @@
~> cat docs/README
~> edit docs/task1/dep1
<var>Provide information about a package <dep1> that is
- a dependency of the meta package <task1>, but does not
+ a dependency of the metapackage <task1>, but does not
contain a useful menu entry.</var>
~> cp docs/task1/dep1 docs/task1/<var><dependent pkg></var>
-~> cp -a docs/task1 docs/<var><meta package name></var>
+~> cp -a docs/task1 docs/<var><metapackage name></var>
</example>
This ensures that our users become aware of all interesting packages
Modified: cdd/trunk/cdd/doc/en/C_bts.sgml
==============================================================================
--- cdd/trunk/cdd/doc/en/C_bts.sgml (original)
+++ cdd/trunk/cdd/doc/en/C_bts.sgml Wed Jul 9 05:25:10 2008
@@ -35,7 +35,7 @@
request at bugs.debian.org a mail containing
<example>
user <email>
- usertag <bug number> + wnpp <meta-package name>
+ usertag <bug number> + wnpp <metapackage name>
</example>,
where email is the electronic address of the person or mailing
list which coordinates the relevant Custom Debian
More information about the Cdd-commits
mailing list