Debian Science Policy Manual

Manuel Prinz

Sylvestre Ledru

Revision History
Revision 1.02012-07-15SL
DM-Upload should not be enabled by default. CDBS is no longer recommended. Debian source package formats 3.0 is now mandatory.
Revision 1.12013-09-11PO
Fix the path to VCS-*; Point the DEP5 link to the correct place; Update the git url; Clarify that /git/ is mounted read-only on and one should log into instead.; Give the reportbug syntax to put debian-maintainers in CC when filling a new ITP bug; Fix example to activate post-update hook in git; Add a link to gpb in section Package Repositories; Fix FIXME requesting internal links
Revision 1.22013-10-25PO
Clarify rules regarding debian/changelog

Table of Contents

About Debian Science
How to Contribute
Becoming a Member
1. Packaging Policy
Debian Control Files
Version Control
The Debian Science Repository
Package Repositories
Build Systems
Patch Systems
ITP/RFP reports
Intend To Package (ITP)
Request For Packaging (RFP)
2. Management of the Debian-Science metapackages
Science related metapackages
Common utilities for all sciences metapackages
How to manage this list
3. Communication vectors
Mailing Lists
User List
Maintainer List
Commit List
A. Help on Packaging
Packaging with Git
Creating a Repository
Importing Upstream Sources
Changes To The Upstream Sources
Publishing Your Repository

List of Examples

1.1. Example debian/control for package "foo"
1.2. Example debian/copyright for package "foo" under GPL


About Debian Science

The main goal of the Debian Science project is to provide a system with all the most important free scientific software in each scientific field.

Debian Science will also manage the debian-science's metapackages.

How to Contribute

A list of packages has been created using Debian Pure Blend. This website contains a long list of software packages in Debian and yet to be packaged. You can help by packaging them in coordination with the Debian Science.

In the meantime, you can also help us by updating the debian-science's metapackages.

Becoming a Member

Before becoming a member you need to have on account on Alioth. If you do not have an account already, you can register one.

To request membership, login to Alioth and use the "Request to join" link on our Debian Science Alioth page. Your application will be processed quickly.

Chapter 1. Packaging Policy

This Packaging Policy describes the packaging rules that packages maintained by the Debian Science Project should follow. The aim is to define a common set of rules to make maintenance easier for everyone involved in the project.

It is not normative as the Debian Policy. If rules or suggestions in this document conflict with the Debian Policy it is a bug in this document.

Debian Control Files

The following sections describe the changes to the control files stored in the source package's debian/ directory.


Changes in the Debian version of the package should be briefly explained in the Debian changelog file. The debian/changelog file consists in a series of entries detailing the changes. The format of the entries is described in the Debian Policy.

Not yet uploaded packages should have only a single changelog entry closing the ITP bug. Indeed, when a package is submitted only the latest paragraph is parsed by the Debian bug tracking system. Therefore do not add new changelog entries when updating an unrealeased package, the VCS logs are enough to track the changes.

When a sponsor is uploading a package for you, mark the package target as UNRELEASED. The sponsor will change it as appropriate before uploading the package.


Section and Priority Fields

The Section field of the source package should be set to "science", unless a more specific section such as "math" is applicable.

The Priority field should be set to "extra" if this is permitted by the Debian Policy, or set to "optional" otherwise.

Maintainer and Uploaders Fields

The Maintainer field should be "Debian Science Maintainers ".

You should also add yourself to the Uploaders field. Doing so shows your involvement and interest in the package. Developers listed in Uploaders will take care of maintenance, bug reports and other QA work, helped by the Debian Science team.

Vcs-Git and Vcs-Browser Fields

If you have your package under version control in the Debian Science Repository, you must set the Vcs-Git and Vcs-Browser fields.

The Vcs-Git field should contain the package repository URL, namely "".

The Vcs-Browser field should point to the web view of your package repository, namely "".

Homepage Field

If an upstream homepage exists, the Homepage field should be set to the upstream homepage URL.


It is a very good idea to use Config::Model to unify the formatting of debian/control. To do so make sure you have installed

apt-get install cme libconfig-model-dpkg-perl libconfig-model-itself-perl

and than you can simply call

cme fix dpkg-control

to get a properly formatted, sanity checked debian/control file. Please note that sometimes you need to call this more than once.


If possible, the machine-readable format should be used.

The license of the packaging work should either match the license of the upstream sources or have a license that is even more free than the upstream license. For example, you should avoid licensing your packaging work under GPL if the upstream license is BSD, even though they are compatible.


If possible, a debian/watch file should be added so upstream releases can be tracked automatically.


In this section you will find example debian/control and debian/copyright files that you can use as a template and modify as needed.

Example 1.1. Example debian/control for package "foo"

Source: foo
Section: science
Priority: extra
Maintainer: Debian Science Maintainers <>
Uploaders: Your Name <>

Example 1.2. Example debian/copyright for package "foo" under GPL

This package was downloaded from

Files: debian/*
Author: Your Name <>
Copyright: Copyright © 2008 Your Name <>
License: GPL-3+
 The Debian packaging is licensed under the GPL, version 3 or later,
 see below.

Files: *
Author: John Doe <>
Copyright: Copyright © 2007-2008 John Doe <>
License: GPL-3+
  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License along
  with the Debian GNU/Linux distribution in /etc/share/common-licenses/GPL.
  If not, see <>.

On Debian systems, the complete text of the GNU General Public License
can be found in /usr/share/common-licenses/GPL.

Version Control

The Debian Science Project has agreed to use Git as their preferred Version Control System (VCS).

Because of Git's nature, each package exists in its own repository. The term "repository" is also used for the location where all packages are stored. It is used in the following sections as defined below:

Git Repository means a (bare) Git repository, containing history information.

Package Repository means a Git Repository that stores packaging information.

Debian Science Repository means the location where all package repositories are stored.

The Debian Science Repository

The Debian Science Repository is located on Alioth in the directory /git/debian-science/. All group members have write access to the directory when logged on but the /git/ directory is mounted as read-only when logged on

The Debian Science Repository is structured by a directory hierarchy containing several Git repositories, other directories and scripts. It is structured like this:

+- debian-science-tools.git
+- packages/
   +- bar.git
   +- baz.git
   +- foo.git
   +- ...
+- papers.git
+- policy.git
+- removed-packages/
   +- qux.git
   +- ...
+- setup-repository

Package Repositories have to be placed in the packages/ sub-directory. They should follow the guidelines in the Package Repositories section.

Package Repositories

The following sections explain the preferred Package Repository layout.

Repository Layout and Structure

Each Package Repository has to be stored as a bare Git Repository inside the packages/ sub-directory of the Debian Science Repository.

The Package Repository name has to be the name of the source package followed by a .git extension. A source package named foo is therefore stored in a Package Repository named foo.git.

Repository Creation

The Package Repository should be created with the setup-repository script in /git/debian-science. Change directory to /git/debian-science/packages and run ../setup-repository with the package name as the first argument. An optional description can be provided as the second argument, which will default to 'Packaging for <package>'.

$ cd /git/debian-science/packages
$ ../setup-repository foo 'Example package for debian-science policy'
Initialized empty shared Git repository in /srv/
Clone URL:


All Package Repositories should contain a common set of branches in order to ease maintenance.

All Debian-specific changes (such as the debian/ directory) should go to a branch named debian or master. If you use several branches to organize your changes, the debian branch should be treated as the integration branch.

If upstream sources are included in the Package Repository they should be stored in a branch named upstream. It can either store upstream sources from a VCS or source tar-ball snapshots.

It is recommended to use pristine-tar to be able to restore upstream tar-balls from the source files in the Package Repository. The delta files produced by pristine-tar should be stored in the pristine-tar branch.

Git-buildpackage follows the above branch conventions and automates the process of importing upstream snapshots.


All imports of source tar-balls or upstream releases (if tracked in the Package Repository) should be tagged as "upstream/${VERSION}". For example, the 1.2.3 release of a package should have a tag "upstream/1.2.3".

Accordingly, all Debian releases of a package should be tagged "debian/${DEB-VERSION}". For example, the second Debian release of the example package in the last paragraph should have a tag "debian/1.2.3-2".

Commit Messages

Each Package Repository should add a commit hook that sends commit messages to the and mailing lists.

If you used the setup-repository script to create your repository, this has already been done. If not, the recommended way is to use the /home/groups/debian-science/bin/debian-science-post-receive script on Alioth. To setup the hook, login to Alioth and change into your Package Repository directory. There you can execute:

$ git config --add hooks.mailinglist ""
$ git config --add hooks.mailinglist ""
$ cat >hooks/post-receive <<END
exec /home/groups/debian-science/bin/debian-science-post-receive
$ chmod 0775 hooks/post-receive

Build Systems

Package maintainers are free to use any build system for packaging (or none at all).

Debhelper is recommend for more complicated packaging.

Patch Systems

quilt and Debian Source Format 3 must be.

If a package is stored in a Package Repository a patch system is not needed technically but the maintainer is free to use one nevertheless.


Debian Science is also managing the Debian-Science metapackages. Consequently, please update the appropriate metapackage with your new package as described in Chapter 2.

ITP/RFP reports

Intend To Package (ITP)

When a Debian Science Maintainer is sending an ITP to the BTS, should be one of the receivers of this ITP. Therefore, members of the team will be informed of the on-going work and could provide help. If using reportbug to file the ITP, this can be accomplished with the following command:

reportbug wnpp

Also please include the pseudo-headers:


Request For Packaging (RFP)

If a RFP of a scientific software is sent to the BTS, this one could be assigned to the team and added to the Debian Science Blend package list.

Chapter 2. Management of the Debian-Science metapackages

Debian Science is also in charge of the Debian-Science metapackages. These packages provide an easy way for a lambda user to get packages in a specific scientific fields.

Science related metapackages

The science related metapackages are:

  • science-astronomy packages related to astronomy

  • science-biology packages related to biology

  • science-biology packages related to biology

  • science-chemistry packages related to chemistry

  • science-electronics packages related to electronics

  • science-geography packages related to geography

  • science-linguistics packages related to linguistics

  • science-mathematics packages related to mathematics

  • science-physics packages related to physics

  • science-robotics packages related to robotics

Common utilities for all sciences metapackages

Common utilities for all sciences metapackages are:

  • science-statistics packages related to statistics

  • science-typesetting packages related to typesetting

  • science-viewing packages related to viewing

How to manage this list


For technical reasons, these files are stored in the Debian Science Blend's VCS.

Checkout the source tree and edit /tasks/* files. These files contain the list of the packages which will be added to the metapackages.

Note that it is also possible to add packages which are not in the Debian archive. These packages will appear on the Blend task list.

Chapter 3. Communication vectors

Mailing Lists

This section briefly explains the purpose of the mailing lists that are under the scope of Debian Science.

User List

The mailing list should be considered a user (support) list.

Maintainer List

The mailing list should be used for all packaging related issues, such as packaging questions and BTS messages.

Commit List

The mailing lists should collect all commit messages from commits to the Package Repositories. All Packages Repositories should have a commit hook that sends commit messages to this list.

Appendix A. Help on Packaging

The following sections are not part of the Debian Science Policy Manual. They should provide useful information for contributors who are not familiar with the tools mentioned in this document.

Packaging with Git

This section will give you guide on packaging Debian packages with Git. Since Git is a very flexible tool, you can (and should!) adopt it to fit your work-flow best. "There is more than one way to do it", as the saying goes, so this document can not show all of them. It's supposed to help you if you are unfamiliar with using Git for packaging work. It is, however, not supposed to be a normative document that everyone has to follow.

Creating a Repository

Git repositories are nothing more than a directory with a special directory storing meta-data, named .git/. Creating and configuring the repository is pretty straight-forward:

$ mkdir foo && cd foo
$ git init
Initialized empty Git repository in .git/
$ git config  "$DEBFULLNAME"
$ git config "$DEBEMAIL"

This creates a new Git directory and sets the user name and email address that will be used in the commit message.

Importing Upstream Sources

It is quite common for packaging with Git that the upstream sources are stored in the repository. It is, however, not strictly necessary. But the costs are rather low and the benefit can be high, so this section will explain ways to import the upstream sources into you repository.

Using git-buildpackage and pristine-tar

There are two tools that will assist you in packaging with Git a lot: git-buildpackage and pristine-tar.

git-buildpackage can import upstream sources, create or import .diff.gzs and build a Debian package from Git repositories. It is similar in function to svn-buildpackage or other VCS-buildpackage tools.

pristine-tar is able to recreate bit-identical upstream tar-balls from the files stored under version control. It does so by creating small delta files, so that it is not necessary to store the whole tar-ball.

To import an upstream tar-ball into your repository, simply run:

$ gbp import-orig --pristine-tar ~/foo_1.0.orig.tar.gz
Upstream version is 1.0
Initial import of '/home/jdoe/foo_1.0.orig.tar.gz' ...
pristine-tar: committed to branch pristine-tar
Succesfully merged version 1.0 of /home/jdoe/foo_1.0.orig.tar.gz into .

After that, you will see two new branches, "upstream" and "pristine-tar":

$ git branch
* master

The upstream branch holds your upstream sources as extracted from the tar-ball. The pristine-tar branch holds the delta files the pristine-tar created. Also, a tag has been created:

$ git tag -l

You can use gbp import-orig for every new upstream tar-ball. It will extract the sources to the upstream branch and merge them back to the master branch.

Changes To The Upstream Sources

There are at least two methods for doing changes to upstream sources. One uses an integration branch, the other one uses a patch system. Both methods have it's benefits and drawbacks, so you have to decide which methods is best for your purpose.

Using An Integration Branch

By using this model, all changes to the upstream sources are made in independent branches and merged back into a special branch, the "integration" branch. This section tries to explain how this works.

When doing changes to the upstream sources, all logical changes should be stored in their own branch, a so-called "feature branch". The hardest part is giving it a reasonable name. If you want to fix a bug submitted to the BTS, you might want to call your branch "bug-nnn", where "nnn" is the bug number. You can also prefix Debian-specific changes with "deb/" to separate them from branches that contain patches which might be included upstream.


You can also store each patch as one commit in a single feature branch, such as "upstream-patches". It is all up to you. Figure out what work-flow you like best.

After you thought of a name, you should branch from the latest upstream version. If you used gbp import-orig, you can use the tags created by it:

$ git checkout -b bug-123456 upstream/1.0

You can now start fixing the bug inside this branch and commit the changes. For every change to the upstream sources, create a new branch and do your fixes in that until you're done. In the last step, it is time to merge the changes back to the integration branch.

Publishing Your Repository

This section will explain how to publish a repository in the Debian Science scope but should be easy to adopt for other teams or locations.

First, login to and create a new shared bare repository:

$ cd /git/debian-science/packages/
$ mkdir foo.git && cd foo.git
$ git --bare init --shared=all

You should also active the post-update-hook to allow checkouts via HTTP.

$ mv hooks/post-update.sample hooks/post-update
$ chmod 0775 hooks/post-update


It is not recommended to use Git over HTTP but it may be handy for people behind a firewall.

You should also create a hook to send out commit emails to the commits mailing list.

The next step only applies if you do not use the "master" branch for storing you debian work. In this case, the HEAD reference in the repository has to be set to point to the branch you are going to push to the repository, or cloning will fail. Assuming your Debian-specific changes are stored in a branch called "debian", do:

$ echo 'ref: refs/heads/debian' > HEAD

The last steps need to be done on your local repository:

$ git remote add alioth ssh://
git push --all alioth
git push --tags alioth

This tells you local repository about your remote repository and exports all of your branches and tags.

All these steps only need to be done once. After that, pushing your changes to the remote repository is all you need to do to publish them.