Table of Contents
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 metapackages by using the blends-dev package. It is perfectly possible to build 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.
~> cp -a /usr/share/doc/blends-dev/examples/tasks . ~> cat tasks/README ~> edit tasks/task1 Description:
short description long description as in any debian/control fileDepends:
dependency1, dependency2, ...
For each metapackage this skeleton of a
entry is needed. All necessary information is available in the
To build any Debian package you always need a directory named
debian, which contains a certain set of files. The
package blends-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/blends-dev/examples/debian . ~> cat debian/README ~> edit debian/control.stub
Now the variables in the file
control.stub change the
_MAINTAINER_ etc. to
match the names of the Debian Pure Blend to be built. Please note
that the file
debian/control is and has to be a symbolic
control.stub to let the
blends-dev tools work.
~> edit debian/rules
Also in the
debian/rules the name of the Blend has to be
inserted where the template contains
_BLEND_. Depending from the way the
sources.list should be scanned the options for the
gen-control call can be adjusted.
You have to build the tarball using the command
~> make -f debian/rules get-orig-source
For your comfort you might like to create a file
#!/usr/bin/make -f include /usr/share/blends-dev/Makefile
which enables you to simply use
~> make dist
to build the source tarball. This tarball has to be moved to a location where the metapackages will be built. Unpack the tarball there and start the build process using for instance
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 blends-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
blend-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/blends-dev/examples/common . ~> cat common/README ~> edit common/conf common/control common/common.1
The variables (
_BLEND_) in these three files have to be
adjusted to the name of the Debian Pure Blend in question.
cares for the initialisation
of the role based menu system and might contain adjustments of the
general configuration inside the blends-common.
If the metapackage
blend-config will be
created according to these rules all other metapackages will depend
automatically from this common package. For the friends of
auto-apt, a helper
<metapackage-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 Section 6.3.1, “User menu tools” the metapackages can contain user menus. This optional feature can be implemented easily by using the template from the blends-dev in the following way:
~> cp -a /usr/share/doc/blends-dev/examples/menu . ~> cat menu/README ~> edit menu/task1
Edit the example to legal menu entries of the dependencies of this metapackage~> cp menu/task1 menu/
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 metapackage 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
blend-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 metapackage maintainer has a good chance for quality
assurance work, which is also part of the Debian Pure Blends
In principle these menu items could be created automatically either at
metapackage build time or even better in the
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 metapackage build machine. This might be implemented in later
versions of blends-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
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 metapackage. Such documentation can be created using the following templates:
~> cp -a /usr/share/doc/blends-dev/examples/docs . ~> cat docs/README ~> edit docs/task1/dep1
Provide information about a package <dep1> that is a dependency of the metapackage <task1>, but does not contain a useful menu entry.~> cp docs/task1/dep1 docs/task1/
<dependent pkg>~> cp -a docs/task1 docs/
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.