Chapter 6. Technology

Table of Contents

6.1. Metapackages
6.1.1. Metapackage definition
6.1.2. Collection of specific software
6.1.3. Packages showing up in more than one metapackage
6.1.4. Adapted configuration inside metapackages
6.1.5. Documentation packages
6.2. Handling of metapackages
6.2.1. Command line tools
6.2.2. Text user interfaces
6.2.3. Graphical user interfaces
6.2.4. Web interfaces
6.2.5. Future handling of metapackages
6.3. User roles
6.3.1. User menu tools
6.4. Development tools
6.5. Dealing with name space pollution

6.1. Metapackages

6.1.1. Metapackage definition

A metapackage, as used by Blends, is a Debian package that contains:

  • Dependencies on other Debian packages (essential)


    Use "Depends" for packages that are definitely needed for all basic stuff of the Blend in question.


    The packages that are listed as "Recommends" in the tasks file should be installed on the machine where the metapackage is installed and which are needed to work on a specific task.


    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 metapackage build time the "Recommends" is turned into a "Suggests" to enable a flawless installation of the metapackage.

  • Menu entries (recommended)

    • Place these in /etc/blends/<blend> /menu/<pkg-name>

    • Maintain these via role based tools

  • Configuration stuff (optional)

  • Special metapackages:

    • <blend>-tasks: Contains information for tasksel

    • <blend>-config: Special configurations, basic stuff for user menus

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 metapackages follows the pattern <blend>-<task> where <blend> stands for the short name of a Debian Pure Blend, e.g. junior for Debian Jr. or med for Debian Med, and <task> means the certain task inside the Blend, e.g. puzzle or bio.



Debian Jr. Puzzles


Tasksel files for SkoleLinux systems


Debian Med micro-biology packages

6.1.2. Collection of specific software

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 20000 packages in Debian to find everything they need. So, metapackages are an easy method to help users to find the packages that are interesting for their work quickly.

If the author of a metapackage includes several packages with similar functionality, an easy comparison between software covering the same task is possible.

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 metapackage is installed.

All in all, metapackages enable an easy installation from scratch, and keep the effort required for administration low.

6.1.3. Packages showing up in more than one metapackage

This seems to be an FAQ: If a package A is in the list of dependencies of metapackage m is it allowed or reasonable to add it to the list of dependencies of metapackage n?

The answer is: Why not?

The "overlap" is no problem because we do not want to build an exclusive categorisation which might be hard to understand for our users. Metapackages are like "normal" packages: Nobody would assume that because package x depends from package libc no other package is allowed to add libc to its depends. So why not adding a dependency to more than one metapackage if it is just useful for a certain task?

The important thing is to support our users. A specific user wants to solve a certain task (and thus installs a certain metapackage). The question whether some Dependencies are also mentioned in a different metapackage is completely useless for this task. So in fact we do not build a categorisation tree but build pools of useful software for certain tasks which can definitely have overlaps.

To give a certain example which was asked by a member of Debian Multimedia team: A user who is seeking for his optimal sound player is not served best if we "hide" an application from his view by including it into sound recorders exclusively. While chances might be good that a sound recorder is not as lightweight as a pure player the user will find out this quickly if he is looking for only a lightweight player - but perhaps he becomes happy later about the "added value" of his favourite player if it also is able to record sound.

6.1.4. Adapted configuration inside metapackages

Besides the simplification of installing relevant packages by dependencies inside metapackages, 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.

6.1.5. Documentation packages

A "traditional" weakness of Free Software projects is missing documentation. To fix this, Debian Pure Blends 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, Debian Pure Blends 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 Debian Pure Blends.

6.2. Handling of metapackages

In short, there are no special tools available to handle metapackages nicely. But there are some tricks that might help, for the moment.

6.2.1. Command line tools


The program apt-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-bio-dev - Debian Med micro-biology development packages
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-common - Debian Med Project common package
med-cms - Debian Med content management systems

This is not really straightforward, and absolutely unacceptable for end users.


The program grep-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-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-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.


The program auto-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 <>

This software is licensed under the GPL.

On Debian systems, the GPL can be found at /usr/share/common-...

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 metapackages as they are used in Debian Pure Blends - just some hacks using the powerful tools inside Debian.

6.2.2. Text user interfaces


The Debian task installer Tasksel 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 Debian Pure Blend. Unfortunately, there are some issues that prevent Blends 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 Blends 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 Blends.

As a workaround for this problem the blends-dev framework creates a package BLEND-tasks which contains a tasksel control file. If you install this package all tasks of the Blend will be added to the default list of tasks inside tasksel. So a solution for Blend specific installation media might be to just remove the default tasksel list and provide the Blends own tasks exclusively.


This is a better replacement for dselect, 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 Debian Pure Blends, and thus there could be some better support to handle metapackages more cleverly.

Short conclusion: There is a good chance metapackages could be handled nicely by the text based Debian package administration tools, but this is not yet implemented.

6.2.3. Graphical user interfaces

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.


This is the native GNOME flavour of graphical user interfaces to apt. It has a nice Search feature that can be found in the Package menu section. If for instance the packages of the Debian Jr. project come into the focus of interest a search for "junior-*" will show up all related packages including their descriptions. This will give a reasonable overview about metapackages of the project.


Even more sophisticated and perhaps the best choice for users of Debian Pure Blends. Synaptic 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 Section 9.3, “Debian Package Tags” ).


This is the user interface of choice for KDE lovers. Regarding its features (with exception of Debian Package Tags) it is similar to both above.

Short conclusion: As well as the text based user interfaces these tools are quite usable but need enhancements to be regarded as powerful tools for Debian Pure Blends.

6.2.4. Web interfaces

Tasks pages

The tasks pages probably provide the best overview about the actual work which is done in a Debian Pure Blend. These pages are automatically generated by reading the tasks files (see Section A.1.2, “debian/control ) and verifying the existence of the packages that are mentioned as dependencies. On the resulting web page the packages are listed with some meta information and the description of the package. As user oriented pages they are translated into more than 10 languages while translated means, the navigation text of the page generating code is using gettext which enables translation (the work is not yet completely done for all languages) but even more importantly the descriptions of the packages are translated as well by using the information from Debian Description Translation Project.

These tasks pages are available via


where BLEND has to be replaced by the name of the Blend. Currently these pages are available for the Blends:

	    accessibility, edu, gis, junior, lex, med, science, debichem

In short: If you want to know more about a specific Blend go to its task page and have a look what is listed there.

Bugs pages

The more developer oriented bugs pages try to match the scope of the tasks pages mentioned above but there is no description of the packages given but rather the bugs that are reported in the Debian Bug Tracking System (BTS) are listed there. This is a quite valuable source of information if somebody is interested in increasing the quality of a Blend: Fixing bugs is always welcome and listing all relevant bugs at a single place is a nice way to detect problems quickly.

These bugs pages are available via


where BLEND has to be replaced by the name of the Blend. Currently these pages are available for the Blends:

	    accessibility, edu, gis, junior, lex, med, science, debichem

In short: If you want to help enhancing the quality of a specific Blend go to its bug page and start working on the bugs listed there.

Web search

Debian has a web interface that can be used to search for certain substrings in package names. For instance if you are searching the meta packages of Debian Med you could point your favourite Browser to

FIXME: & is sometimes broken!!! ^^^^^

As a result you will get a list of all Debian Med packages.

Package Tracking System

The Package Tracking System is a really great tool that provides essential information about packages. Most Debian Pure Blends are using a mailing list address as Maintainer of their key packages which includes the metapackages. This so called team maintenance of packages is on one hand very handy from a developers point of view on the other hand it enables using the Package Tracking System to get a quick overview:

Hint: If you append the option &ordering=3 you might get some sectioning of this page according to the metapackage categories. This result is approached by a tool which subscribes all dependent packages to the group maintenance address and adds a section according to a metapackage name.

The other way to use the Package Tracking System is to search for packages starting with a certain letter:

But the list that is obtained by this method is much larger than it would be useful for a good overview.

The package junior-doc contains a script /usr/share/doc/junior-doc/examples/scripts/ that checks for the installed packages of a Blend and builds a simple web page describing these packages. (The BTS contains a patch to let this script work also for other Blends.)

Short conclusion: The Debian Pure Blends provide some nice web tools for a whole set of packages for a certain working field that provide a better overview than the usual Debian tools that are basically dealing with single packages..

6.2.5. Future handling of metapackages

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:

  • Searching for existing metapackages

  • Overview about dependencies of these metapackages

  • Enhancing tools like aptitude, synaptic, etc.

  • Special tasksel section

  • Web tools that keep metapackage information up to date

Furthermore it is necessary to find a set of keywords for each Debian Pure Blend 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 metapackages have to be written or rather the available tools for this should be patched for this actual functionality.

6.3. User roles

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 Blend, which are called "roles". There are several techniques available to manage user roles. Currently in the field of Debian Pure Blends a UNIX group based role system is implemented. This means, that a user who belongs to a certain group of a Blend 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 Debian Pure Blends 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 Debian Pure Blends 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.

6.3.1. User menu tools Using the Debian menu system

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 blend-update-menus(8) (see Section A.2.2, “blend-update-menus(8)) script from blends-common. It has to be said that using blend-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 Blend is necessary if this is not done by the postinst script of a metapackage. This can easily been done if the configuration file of a Debian Pure Blend /etc/blends/<blend>/<blend>.conf contains the line


It is strongly suggested to use the package blends-dev to build metapackages of a Debian Pure Blend that will move all necessary files right into place if there exists a menu directory with the menu entries. Note, that the users ${HOME}/.menu directory remains untouched. Managing Debian Pure Blend users with debconf

Using blends-dev it is very easy to build a blend-config package that contains debconf scripts to configure system users who should belong to the group of users of the Debian Pure Blend blend. 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.)

6.4. Development tools

Building a metapackage is more or less equal for each meta package. This was the reason to build a common source package blend that builds into two binary packages


Helpful tools to build metapackages from a set of template files. These tools are interesting for people who want to build metapackages in the style Debian Edu and Debian Med are currently doing this. The purpose of this package is to make maintenance of metapackages as easy as possible.

This package is described in detail in appendix Section A.1, “Package blends-dev.


This package provides some files that are common to meta packages of Debian Pure Blends especially those that were built using the tools of the package blends-dev. It introduces a method to handle system users in a group named according to the name of the Blend. The user menu approach is explained in detail in Section 6.3, “User roles”.

This package is described in detail in appendix Section A.2, “Package blends-common.

The usage of the tools that are contained in these packages are described now in detail.

6.5. Dealing with name space pollution

Due to the fact that Blends might deal with quite specialised software the user base is often quite small. In such use cases it happens that some programs are using names that are used by other more frequently used tools. For instance the Debian Med program plink has the same name as the program plink that belongs to the ssh clone putty. According to the Debian policy both packages, putty and plink need to be co-installable. Thus one tool has to be renamed.

Name space conflicts in Debian are usually solved by the principle that whoever comes first has taken the name if there is no better agreement. However, it makes sense to keep the original name chosen by upstream for the more frequently used program - and here it might be that the Blends packager steps back. There might be a chance to discuss with upstream about a better name but there is no guarantee that this will be successfully and thus there is another option for the Blends developer to provide the original upstream name to the Blends users by circumventing the file name conflict - at least for users of the bash shell.

Since blends-dev >= in the blend-config a bash init script is provided in


This script is executed in login shells and checks for two things:

  1. Does the path /usr/lib/<BLEND-name>/bin exist (since a package installs files there)?

  2. Has the user starting the bash instance created a file $HOME/.blends and is there a line featuring the name of the Blend (in the example above "debian-med")

If both conditions are fulfilled the PATH gets prepended by /usr/lib/<BLEND-name>/bin and thus the tools residing in this directory were found first.

Moreover also MANPATH is prepended by /usr/lib/<BLEND-name>/share/man to enable providing proper manpages to the binaries in the Blends private PATH. Otherwise it might happen that a user might see a manpage of the executable in /usr/bin which is not the first in the search PATH any more. The location is a topic of further discussion since manpages under /usr/lib are in conflict with FHS.