A meta package, as used by CDDs, is a Debian package that contains:
/etc/cdd/<cdd>/menu/<pkg-name>
debconf questions or pre-seeding
cfengine scripts (or similar see Enhancing basic technologies
regarding Custom Debian Distributions, Section 8.4)
<cdd>-common
Meta packages 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 <cdd>-<task>
where <cdd> stands for the short name of a Custom Debian
Distribution, e.g. junior for Debian Jr. or med for
Debian-Med, and <task> means the certain task inside the
Custom Debian Distribution, e.g. puzzle or bio.
Examples:
junior-puzzledebian-edu-configmed-bioWhen using meta packages, 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 find the packages that are interesting for their work quickly.
If the author of a meta package includes several packages with similar functionality, an easy comparison between software covering the same task is possible.
Moreover, the installation of a meta package 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 helps non specialist administrators to keep the installation fit for the specialized users.
By defining conflicts with some other packages inside the meta package, 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.
All in all, meta packages enable an easy installation from scratch, and keep the effort required for administration low.
Besides the simplification of installing relevant packages by dependencies
inside meta packages, these packages might contain special configuration for
the intended task. This might either be accomplished by pre-seeding
debconf questions, or by modifying configuration files in a
postinst script. It has to be ensured that no changes that have
been done manually by the administrator will be changed by this procedure. So
to speak, the postinst script takes over the role of a local
administrator.
A "traditional" weakness of Free Software projects is missing
documentation. To fix this, Custom Debian Distributions try to provide
relevant documentation to help users to solve their problems. This can be done
by building *-doc packages of existing documentation, and by
writing extra documentation, like manpages, etc. By supplying documentation,
Custom Debian Distributions fulfil their role in addressing the needs of
specialised users, who have a great need for good documentation in their native
language.
Thus, translation is a very important thing to make programs more useful for
the target user group. Debian has established a Debian Description Translation
Project, which has the goal to translate package descriptions.
There is a good chance this system could also be used for other types of
documentation, which might be a great help for Custom Debian Distributions.
In short, there are no special tools available to handle meta packages nicely. But there are some tricks that might help, for the moment.
apt-cacheapt-cache is useful to search for relevant keywords in
package descriptions. With it, you could search for a certain keyword
connected to your topic (for instance "med") and combine
it reasonably with grep:
~> apt-cache search med | grep '^med-'
med-bio - Debian-Med micro-biology packages
med-common-dev - Debian-Med Project common files for developing...
med-dent - Debian-Med package for dental practice client
med-doc - Debian-Med documentation packages
med-imaging - Debian-Med imaging packages
med-imaging-dev - Debian-Med packages for medical image develop...
med-tools - Debian-Med several tools
med-bio-contrib - Debian-Med micro-biology packages (contrib an...
med-common - Debian-Med Project common package
med-cms - Debian-Med content management systems
This is not really straightforward, and absolutely unacceptable for end users.
grep-dctrlgrep-dctrl is a grep for Debian package information,
which is helpful for extracting specific package details matching certain
patterns:
~> grep-dctrl ': med-' /var/lib/dpkg/available | \
grep -v '^[SIMAVF]' | \
grep -v '^Pri'
Package: med-imaging
Depends: paul, ctsim, ctn, minc-tools, medcon, xmedcon, med-common
Description: Debian-Med imaging packages
Package: med-dent
Depends: debianutils (>= 2.6.2), mozilla-browser | www-browser, ...
Description: Debian-Med package for dental practice client
Package: med-bio
Depends: bioperl, blast2, bugsx, fastdnaml, fastlink, garlic...
Description: Debian-Med micro-biology packages
Package: med-common
Depends: adduser, debconf (>= 0.5), menu
Description: Debian-Med Project common package
Package: med-common-dev
Depends: debconf (>= 0.5)
Description: Debian-Med Project common files for developing ...
Package: med-tools
Depends: mencal, med-common
Description: Debian-Med several tools
Package: med-doc
Depends: doc-linux-html | doc-linux-text, resmed-doc, med-co...
Description: Debian-Med documentation packages
Package: med-cms
Depends: zope-zms
Description: Debian-Med content management systems
Package: med-imaging-dev
Depends: libgtkimreg-dev, ctn-dev, libminc0-dev, libmdc2-dev...
Description: Debian-Med packages for medical image development
Package: med-bio-contrib
Depends: clustalw | clustalw-mpi, clustalx, molphy, phylip, ...
Description: Debian-Med micro-biology packages (contrib and ...
This is, like the apt-cache example, also a bit
cryptic, and again is not acceptable for end users.
auto-aptauto-apt is really cool if you are running a computer
that was installed from scratch in a hurry, and are sitting at a tradeshow
booth preparing to do a demo. If you had no time to figure out which packages
you needed for the demo were missing so you could install all of them in
advance, you could use auto-apt in the following manner to
guarantee that you have all of the files or programs you need:
~> sudo auto-apt update
put: 880730 files, 1074158 entries
put: 903018 files, 1101981 entries
~> auto-apt -x -y run
Entering auto-apt mode: /bin/bash
Exit the command to leave auto-apt mode.
bash-2.05b$ less /usr/share/doc/med-bio/copyright
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
bugsx fastlink readseq
The following NEW packages will be installed:
bugsx fastlink med-bio readseq
0 packages upgraded, 4 newly installed, 0 to remove and 183 ...
Need to get 0B/1263kB of archives. After unpacking 2008kB wi...
Reading changelogs... Done
Selecting previously deselected package bugsx.
(Reading database ... 133094 files and directories currently...
Unpacking bugsx (from .../b/bugsx/bugsx_1.08-6_i386.deb) ...
Selecting previously deselected package fastlink.
Unpacking fastlink (from .../fastlink_4.1P-fix81-2_i386.deb) ...
Selecting previously deselected package med-bio.
Unpacking med-bio (from .../med-bio_0.4-1_all.deb) ...
Setting up bugsx (1.08-6) ...
Setting up fastlink (4.1P-fix81-2) ...
Setting up med-bio (0.4-1) ...
localepurge: checking for new locale files ...
localepurge: processing locale files ...
localepurge: processing man pages ...
This package is Copyright 2002 by Andreas Tille <tille@debian.org>
This software is licensed under the GPL.
On Debian systems, the GPL can be found at /usr/share/common-...
/usr/share/doc/med-bio/copyright
Just do your normal business - in the above example, less
/usr/share/doc/med-bio/copyright - and if the necessary package is not
yet installed, auto-apt will care for the installation and proceed
with your command. While this is really cool, this is not really
intended for a production machine.
The short conclusion here is: There are no sophisticated tools that might be helpful to handle meta packages as they are used in Custom Debian Distributions - just some hacks using the powerful tools inside Debian.
dselecttaskselTasksel is the first interface for
package selection that is presented to the user when installing a new computer.
The End-user section should contain an entry for each Custom
Debian Distribution. This is currently the case for Debian-Jr.
Debian Task Installer v1.43 - (c) 1999-2003 SPI and others
————— Select tasks to install —————
–– End-user ––––
[X] Debian Jr.
[ ] Desktop environment
[ ] Games
[ ] Linux Standard Base
[ ] X window system
[ ] Office environment
–– Hardware Support ––––
[ ] Dialup internet
[ ] Laptop
[ ] Broadband internet connection
–– Servers ––––
[ ] DNS server
[ ] File server
[ ] Mail server
[ ] Usenet news server
[ ] SQL database
[ ] Print server
[ ] Conventional Unix server
<Finish> <Task Info> <Help>
Unfortunately, there are some issues that prevent further Custom Debian
Distributions from being included in the tasksel list, because the
dependencies of this task can affect what appears on the first installation CD.
This problem would be even greater if all Custom Debian Distributions were
added, and so a different solution has to be found here. (See #186085.) In principle,
tasksel is a good tool for easy installation of Custom Debian
Distributions.
aptitudedselect, and has some 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.
Short conclusion: There is a good chance meta packages could be handled nicely by the text based Debian package administration tools, but this is not yet implemented.
Debian Woody does not contain a really nice graphical user interface for the Debian package management system. But the efforts to support users with an easy to use tool have increased, and so there there will be some usable options in Sarge.
gnome-aptsynapticSynaptic has a nice filter feature, which makes it
a great tool here. Moreover synaptic is currently the only user
interface that supports Debian Package Tags (see Debian Package Tags, Section 8.3).
kpackageShort conclusion: As well as the text based user interfaces these tools are quite usable but need enhancements to be regarded as powerful tools for Custom Debian Distributions.
Web search
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=med-\|[amp
]\|subword=1
As a result you will get a list of all Debian-Med packages.
Package Tracking Systemhttp://qa.debian.org/developer.php?login=synrg
http://qa.debian.org/developer.php?login=tille
http://qa.debian.org/developer.php?login=pere
The other way to use the Package Tracking System is to search for packages starting with a certain letter:
http://packages.qa.debian.org/j
http://packages.qa.debian.org/m
But the list that is obtained by this method is much larger than it would be useful for a good overview.
So the conclusion is - we just need better support here for Custom Debian Distributions.
list-junior.shjunior-doc contains a script
/usr/share/doc/junior-doc/examples/scripts/list-junior.sh that
checks for the installed packages of a Custom Debian Distribution and builds a
simple web page describing these packages. (The BTS contains a patch to let
this script work also for other Custom Debian Distributions.)
Short conclusion: Some very basic things can be done with the web interfaces described above but techniques have to be developed to provide useful information about each Custom Debian Distribution.
Obviously there are no nifty tools as you might know them from Debian available
yet. The user interfaces for apt-get have to be enhanced
drastically to make them easy enough to make them useful in the hands of an end
user. This might implicitly mean that we need some additional control fields
in dpkg to implement reasonable functionality. The following
items are target of future development:
aptitude, synaptic, etc.
tasksel section
Furthermore it is necessary to find a set of keywords for each Custom Debian Distribution and write a tool to search these keywords comfortable. The best way to accomplish this might be to make use of Debian Package Tags, which is a quite promising technique.
Tools that grep the apt cache directly for meta packages have to be written or rather the available tools for this should be patched for this actual functionality.
As stated above specialists have only interest in a subset of the available software on the system they are using. In an ideal world, this would be the only software that is presented in the menu. This would allow the user to concentrate on his real world tasks instead of browsing large menu trees with entries he does not understand.
To accomplish this, a technique has to be implemented that allows to define a
set of users who get a task-specific menu while getting rid of the part of
software they are not interested in. Moreover this has to be implemented for
certain groups of users of one Custom Debian Distribution, which are called
"roles". There are several techniques available to manage user
roles. Currently in the field of Custom Debian Distributions a UNIX group
based role system is implemented. This means, that a user who belongs to a
certain group of a Custom Debian Distribution is mentioned in the
/etc/group file in the appropriate group and gets a special user
menu that is provided for exactly this group.
Strictly speaking it is not the best solution to conflate a configuration mechanism, which users see with menus, with access control, i.e. unix groups. It might be confusing, and wastes the limited number of groups to which a user can belong. On the other hand this is a solution that works for the moment, and has no real negative impact on the general use of the system. The benefit of using unix groups is that there is a defined set of tools provided to handle user groups. This makes life much easier; there is no practical limit to the number of groups to which a user may belong for the existing Custom Debian Distributions at this time.
In the long run, this role system might even be enhanced to certain "levels" a user can have and here the UNIX groups approach will definitely fail and has to be replaced by other mechanisms. This will include the possibility to enable the user adjust his own level ("novice", "intermediate", "expert") while only the administrator is able to access the UNIX groups. On the other hand such kind of user level maintenance is not only a topic for Custom Debian Distributions but might be interesting for Debian in general.
Another point that speaks against using UNIX groups for role administration is the fact that local administrators are not in all cases competent enough to understand the UNIX role concept as a security feature and thus a real role concept including tools to maintain roles are needed in the future.
The handling of the user menus according to the groups is implemented in a flexible plugin system and other ways of handling groups (i.e. LDAP) should be easy to implement.
The Debian menu system cares for menu updates after each package installation.
To enable compliance with the role based menu approach it is necessary
to rebuild the user menu after each package installation or after adding new
users to the intended role. This can be done by using the
cdd-update-menus(8) (see cdd-update-menus(8), Section
6.4.2.2) script from cdd-common. It has to be said that using
cdd-update-menus is not enough to change the menu of a user. To
accomplish this a call of the general update-menu script for every
single user of a Custom Debian Distribution is necessary if this is not done by
the postinst script of a meta package. This can easily been done
if the configuration file of a Custom Debian Distribution
/etc/cdd/<cdd>/<cdd>.conf
contains the line
UPDATEUSERMENU=yes
It is strongly suggested to use the package cdd-dev to build meta
packages of a Custom Debian Distribution that will move all necessary files
right into place if there exists a menu directory with the menu
entries as described in cdd-install-helper(1), Section
6.4.1.2. Note, that the users ${HOME}/.menu directory remains
untouched.
debconf
Using cdd-install-helper(8) (see cdd-install-helper(1), Section
6.4.1.2) it is very easy to build a cdd-common
package that contains debconf scripts to configure system users
who should belong to the group of users of the Custom Debian Distribution
cdd. For example see the med-common package.
~> dpkg-reconfigure med-common
Configuring med-common
----------------------
Here is a list of all normal users of the system. Now you can select those users who
should get a Debian-Med user menu.
1. auser (normal user A) 6. fmeduser (med user F)
2. bmeduser (med user B) 7. glexuser (lex user G)
3. cjruser (jr user C) 8. hmeduser (med user H)
4. djruser (jr user D) 9. iadmin (administrator I)
5. eadmin (administrator E) 10. juser (normal user J)
(Enter the items you want to select, separated by spaces.)
:-! Please specify the Debian-Med users! 2 8
This example shows the situation when you dpkg-reconfigure
med-common if med user B and med user H were
defined as users of Debian-Med previously and med user F should be
added to the group of medical staff. (For sure it is more convenient to use
the more comfortable interfaces to debconf but the used SGML DTD
does not yet support screen
shots.)
Building a meta package is more or less equal for each meta package. This was
the reason to build a common source package cdd that builds into
two binary packages
cdd-devcdd-commoncdd-dev. It introduces a method to handle system users in
a group named according to the name of the Custom Debian Distribution. The
user menu approach is explained in detail in User roles,
Section 6.3.
The usage of the tools that are contained in these packages are described now in detail.
cdd-dev
If meta packages are builded using the tools inside the cdd-dev
package it can be ensured that the resulting meta packages will work nicely
with the same version of cdd-common package. The goal is to keep
necessary changes for the source of the meta packages of a Custom Debian
Distribution as low as possible when the version of the cdd source
package changes. Thus it is strongly recommended to use the tools described
below.
The usage of the tools in the cdd-dev package might introduce a
versioned dependency in the <cdd>-common package
from which all other meta packages of the CDD in question will
depend. This <cdd>-common package instantiates
the CDD in the common registry for all CDDs in
/etc/cdd.
The current Debian-Med packages provide a working example how to use the tools described below.
cdd-gen-control - install menu and link to helper bin and
according manpage
cdd-gen-control
cdd-gen-control parses the tasks directory
for text files that have a similar syntax to debian/control files.
Each text file is used as template for a
cdd-textfile_name meta package and has to
define the dependencies.
debian/control.stub.
/etc/cdd/sources.list is used
to verify which packages are available. You can specify one of
stable, testing or unstable as argument
or a complete path to a valid sources.list file.
pere@hungry.com, Andreas Tille
tille@debian.org
The interesting thing in this script is that it can be ensured that the resulting meta package can be installed in the target distribution. For instance it might be possible that for certain reasons a meta package should work together with the current Debian stable distribution. If the package is built against a sources.list package that contains entries for stable and some newer packages are not yet available, those packages are not listed as dependencies but only as suggested packages. That way, it is possible to provide meta packages for a stable distribution using the same package source as for testing or unstable, where new packages normally go.
cdd-install-helper - install menu and link to helper bin and
according manpage
cdd-install-helper
debian/rules file to install the user
menu files to
/etc/cdd/<cdd>/menu/<package>,
a link for the helper script of every <cdd>-* package and the
link to the manpage for this script.
menumenu exists in the building directory it checks for
files named like meta packages (without the <cdd>- name
prefix). These files should be valid menu files as they are provided for
Debian packages in debian/menu. They will be copied to
debian/<pkg>/etc/cdd/<cdd>/menu/<pkg>
where tools like cdd-update-menus(8) will expect them.
A check will be performed whether there are text files named
docs/<pkg_without_cdd-prefix>/<dependency>.txt
where <dependency> is a package that is listed in the
dependencies of the meta-package. These files should provide reasonable
information how to use this program in text form that can be viewed by a
pager, which is better than having no menu entry at all. A menu
entry will be created that calls the pager to view this text file
after checking whether this package is really listed in the dependencies.
commoncommon/common and has a size greater than 0
a <cdd>-common package is builded. The file
common/control was just used to build the appropriate
debian/control file using the cdd-gen-control(1)
tool.
docsdocs/<pkg_without_cdd-prefix>/ will
be copied to the appropriate doc directory of the meta-package.
confcommon/conf and has a size greater than 0
this is used as that special configuration file
/etc/cdd/<cdd>/<cdd>.conf, which
can override variables from the general configuration file
/etc/cdd/cdd.conf or add further variables. Because it is sourced
from shell, it has to follow shell syntax.
debian-med
source package.
tille@debian.org.
sources.list files in /etc/cdd/
These files are used by cdd-gen-control(1) to build valid
debian/control files that contain only available packages in their
dependencies. This enables building meta packages for stable,
testing, unstable or even a completely different
distribution that has valid sources.list entries. The file
/etc/cdd/control.list is used as default for
cdd-gen-control(1) and usually is a symbolic link (see
ln(1)) to sources.list.distribution. It
might be changed using the -sdist option of
cdd-gen-control(1).
TODO: Either parse the available
/etc/apt/sources.list or use a sane debconf question
to use the "nearest" mirror.
/usr/share/cdd/templates
The directory /usr/share/cdd/templates contains templates that can
be used to build a <cdd>-common, which uses the
tools that are contained in the cdd-common package, and are useful
to manage <cdd> user groups (see User
roles, Section 6.3).
cdd-common
This package creates a common registry for all CDDs in /etc/cdd.
Each CDD should put the files that are used into a subdirectory named like the
CDD of /etc/cdd. The cdd-common package installs a
common configuration file /etc/cdd/cdd.conf, which can be used to
influence the behaviour of the tools described below.
cdd-role - add/remove roles in registered Custom Debian
Distribution
cdd-role add|del CDD [Role]
tille@debian.org, Cosimo Alfarano
kalfa@debian.org.
cdd-update-menus - add menu of meta package to all Custom Debian
Distribution users
cdd-update-menus [--cdd CDD | --user user]
If it is called by a user, it adds, and keeps updated, menu entries for the user who runs it.
If it is called by root, it adds and keeps updated user's menu entries (see menu package for users' menus) for all users who belong to the group of the specified Custom Debian Distribution, or only for a specified user, depending on which parameter is passed to the script.
tille@debian.org, Cosimo Alfarano
kalfa@debian.org.
cdd-user - add/remove user to Role of a registered Custom Debian
Distribution
cdd-user add|del CDD user
[Role]
tille@debian.org, Cosimo Alfarano
kalfa@debian.org.
cdd.conf - configuration for Custom Debian Distribution registry
cdd-common and thus it has to follow shell syntax. The
variables that are set inside this configuration file can be overriden by
special CDD configration files
/etc/cdd/<>cdd>/<>cdd>.conf
for each single CDD.
cdd-role (8), cdd-update-menus (8), cdd-user
(8)
tille@debian.org, Cosimo Alfarano
kalfa@debian.org.
There are several descriptions available how to build Debian packages in
general. The main resource might be the repository of Debian packaging
manuals (especially developers
reference chapter 6, best packaging practices). There are several
external packaging HOWTOs for example the one from Joe
'Zonker' Brockmeier.
This howto describes the building of meta packages by using the
cdd-dev package. It is perfectly possible to build a meta package
as any other normal Debian package but this HOWTO has the only purpose to
describe the profit you might gain by using these tools.
~> cp -a /usr/share/doc/cdd-dev/examples/tasks .
~> cat tasks/README
~> edit tasks/task1
Description: short description
long description as in any debian/control file
Depends: dependency1, dependency2, ...
For each meta package this skeleton of a debian/control entry is
needed. All necessary information is available in the directory
/usr/share/doc/cdd-dev/examples/tasks.
To build any Debian package you always need a directory named
debian, which contains a certain set of files. The package
cdd-dev provides a complete set of example files that only have to
be copied and after editing some place holders are ready to use.
~> cp -a /usr/share/doc/cdd-dev/examples/debian .
~> cat debian/README
~> edit debian/control.stub
Now the variables in the file control.stub change the variables
named _CDD_, _MAINTAINER_ etc. to match the names of the
Custom Debian Distribution to be built. Please note that the file
debian/control is and has to be a symbolic link to
control.stub to let the cdd-dev tools work.
~> edit debian/rules
Also in the debian/rules the name of the Custom Debian
Distribution has to be inserted where the template contains _CDD_.
Depending from the way the sources.list should be scanned the
options for the gen-control call can be adjusted (see cdd-gen-control(1), Section
6.4.1.1).
Optionally a source tarball can be created by
~> make -f debian/rules dist
This tarball can be moved to any location where the meta packages should be built or the build process is started directly by calling
~> debuild
which also creates a source tarball.
That's all for the very simple case when the meta packages should not contain
user menus. Even if user menus are suggested they are not necessary. The
following paragraphs describe how to use the cdd-dev tools to
support these menus.
The creation of a common package is optional, but suggested, because it adds
some special features like menus, user groups, and probably more in the future.
It is automatically built by cdd-install-helper, which is called
in debian/rules, if the common directory exists. The
easiest way to create this is as follows:
~> cp -a /usr/share/doc/cdd-dev/examples/common .
~> cat common/README
~> edit common/conf common/control common/common.1
The variables (_CDD_) in these three files have to be adjusted to
the name of the Custom Debian Distribution in question. This
cdd-common cares for the initialisation of the role
based menu system and might contain adjustments of the general configuration
inside the cdd-common.
If the meta package cdd-common will be created
according to these rules all other meta packages will depend automatically from
this common package. For the friends of auto-apt, a helper
/usr/bin/<meta-package-name> 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.
As explained in User menu tools, Section 6.3.1 the
meta packages can contain user menus. This optional feature can be implemented
easily by using the template from the cdd-dev in the following
way:
~> cp -a /usr/share/doc/cdd-dev/examples/menu .
~> cat menu/README
~> edit menu/task1
Edit the example to legal menu entries of the
dependencies of this meta package
~> cp menu/task1 menu/<meta package name>
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. The only thing that has to be changed in
these menu entries is the package field, which has to be changed
from <dependent package> to
cdd-task. All other entries 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 assurance work, which is also
part of the Custom Debian Distributions issue.
In principle these menu items could be created automatically either at meta
package build time or even better in the postinst script of the
meta package 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 versions of cdd-dev. 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 packages that do not provide a menu entry. If this is the case
because the package maintainer just forgot it a bug report should be filed. On
the other hand, there are packages with programs that provide a command line
interface that does not allow a reasonable menu entry. A solution for this
case is provided in the next paragraph.
The idea of the meta package 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 the following templates:
~> cp -a /usr/share/doc/cdd-dev/examples/docs .
~> cat docs/README
~> edit docs/task1/dep1
Provide information about a package <dep1> that is
a dependency of the meta package <task1>, but does not
contain a useful menu entry.
~> cp docs/task1/dep1 docs/task1/<dependent pkg>
~> cp -a docs/task1 docs/<meta package name>
This ensures that our users become aware of all interesting packages on their system. The documentation files should contain hints to man pages to read, URLs that should be visited to learn more about the package or some short introduction how to get started.
Custom Debian Distributions
12 August 2004tille@debian.org