| Revision History | ||
|---|---|---|
| Revision 1.0 | 2012-07-15 | SL |
| DM-Upload should not be enabled by default. CDBS is no longer recommended. Debian source package formats 3.0 is now mandatory. | ||
| Revision 1.1 | 2013-09-11 | PO |
| 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 alioth.debian.org and one should log into git.debian.org 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.2 | 2013-10-25 | PO |
| Clarify rules regarding debian/changelog | ||
| Revision 1.3 | 2018-02-02 | JC |
| Work in progress: update to reflect migration from Alioth to Salsa. | ||
| Revision 1.4 | 2018-02-13 | BP |
| 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
List of Examples
Table of Contents
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.
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.
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.
Table of Contents
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.
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.
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".
The Maintainer field should be "Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>".
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.
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
"https://salsa.debian.org/science-team/foo.git".
The Vcs-Browser field should point to the
web view of your package repository, namely "https://salsa.debian.org/science-team/foo".
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: optional Homepage: https://foo.example.org/ Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org> Uploaders: Your Name <your.name@debian.org> Vcs-Git: https://salsa.debian.org/science-team/foo.git Vcs-Browser: https://salsa.debian.org/science-team/foo
Example 1.2. Example debian/copyright for package "foo" under GPL
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: SOFTware Upstream-Contact: John Doe <john.doe@example.com> Source: http://www.example.com/software/project Files: * Author: John Doe <john.doe@example.org> Copyright: Copyright © 2007-2008 John Doe <john.doe@example.org> License: GPL-3+ Files: debian/* Author: Your Name <your.name@debian.org> Copyright: Copyright © 2008 Your Name <your.name@debian.org> 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 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 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 <https://www.gnu.org/licenses/>. . On Debian systems, the complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-3.
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 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 Maintainer level of access
other members (including Debian Maintainers) have a Developer level of access
See GitLab documentation for details.
The following sections explain the preferred Package Repository layout.
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).
Each group member with Maintainer 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 Maintainer.
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".
Package maintainers are free to use any build system for packaging (or none at all).
Debhelper is recommend for more complicated packaging.
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.
When a Debian Science Maintainer is sending an ITP to the BTS, <debian-science@lists.debian.org> 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 --list-cc=debian-science@lists.debian.org wnpp
Also please include the pseudo-headers:
User: debian-science@lists.debian.org Usertags: field..THE_FIELD_OF_YOUR_PACKAGE
Table of Contents
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.
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 are:
science-statistics packages related to statistics
science-typesetting packages related to typesetting
science-viewing packages related to viewing
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.
Table of Contents
This section briefly explains the purpose of the mailing lists that are under the scope of Debian Science.
The <debian-science@lists.debian.org> mailing list is used for communication between package maintainers, software developers and other people involved in packaging of software.
The <debian-science-maintainers@lists.alioth.debian.org> mailing list is used for automatically generated messages, such as BTS and Debian queue daemon messages.
This Debian Science Policy is maintained on salsa.debian.org/science-team/policy. 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.
Table of Contents
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.
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.
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 user.name "$DEBFULLNAME" $ git config user.email "$DEBEMAIL"
This creates a new Git directory and sets the user name and email address that will be used in the commit message.
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.
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 foo_1.0.orig.tar.gz.delta 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 pristine-tar upstream
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 upstream/1.0
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.
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.
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.
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@salsa.debian.org:science-team/foo.git 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.