Debian Science Policy Manual

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
Revision 1.32018-02-02JC
Work in progress: update to reflect migration from Alioth to Salsa.
Revision 1.42018-02-13BP
Updates to reflect changes in Debian Policy; fix example of debian/copyright; update Blends URL; update copyright-format URL; update most of http URLs to https. Finish updates related to migration from Alioth to Salsa: rewrite "Mailing Lists", "The Debian Science Repository", "Repository Layout and Structure", "Repository Creation" and "Publishing Your Repository" sections, update "Intend To Package (ITP)" section, delete "Commit Messages" section.

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
Maintaining of this Policy
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 Salsa. If you do not have an account already, you can register one.

To request membership, login to Salsa and use the "Request to join" link on our Debian Science Salsa 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 "optional".

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

Upstream-Name: SOFTware
Upstream-Contact: John Doe <>

Files: *
Author: John Doe <>
Copyright: Copyright © 2007-2008 John Doe <>
License: GPL-3+

Files: debian/*
Author: Your Name <>
Copyright: Copyright © 2008 Your Name <>
License: GPL-3+

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-3.

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 Salsa.

All group members have write access to all Package Repositories, but there is some difference in access levels:

  • all Debian Developers have at least Master level of access

  • other members (including Debian Maintainers) have a Developer level of access

See GitLab documentation for details.

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 in Debian Science Repository (group in terms of GitLab) or in one of its thematic sub-directories (sub-groups in terms of GitLab).

Repository Creation

Each group member with Master level of access (or higher) may create new Package Repositories in group using standard GitLab features (Web UI and Web API). Another way is to create personal Package Repository on Salsa and then transfer it to Debian Science Repository. Do not forget to check a visibility of transferred repository (public or private). Only group members with Owner level of access may change the visibility of Package Repository.

Group members with Developer level of access may ask for Package Repository creation from group members with higher level of access directly or in team mailing list. Transferring of personal Package Repositories is not accessible for them. If such transfer is absolutely necessary, the access level of group member may be temporary changed to Master.


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".

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 is used for communication between package maintainers, software developers and other people involved in packaging of software.

Maintainer List

The mailing list is used for automatically generated messages, such as BTS and Debian queue daemon messages.

Maintaining of this Policy

This Debian Science Policy is maintained on Any member of the Debian Science is able to make proposal about updating of this document. Open discussion is needed if the critical parts of the Policy are affected.

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

Instructions how to create Package Repository on Salsa are described above.

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

$ git remote add origin
git push --all origin
git push --tags origin

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.