Table of Contents
Debian-Med is a “Custom Debian Distribution” with the aim to develop Debian into an operating system that is particularly well fit for the requirements for medical practice and research.
The Debian-Med project presents packages that are associated with medicine, pre-clinical research, and life sciences. Its developments are mostly focused on three areas for the moment: medical practice, imaging and bioinformatics.
Over the previous years, several initiatives have spawned that address the scientific disciplines like chemistry or bioinformatics. Debian-Med is not a competition to these efforts but a platform to present the packages to the community as a Custom Debian Distribution.
From the developer to the user, there is a long chain of tasks in which we always welcome participation. First we must keep ourselves informed about the software landscape in biology and medicine. Software to be packaged is chosen according to criteria such as users' need and the consistency of the distribution.
Once in Debian, the software is monitored for its quality and bugs are fixed, if possible in collaboration with the upstream maintainer(s). All this work would not be very useful if it remains confidential.
We also dedicate some time to advertise it to the world via www.debian.org and to ease the integration of new members.
Please contact us on debian-med@lists.debian.org if you want to help to make medical and biological software available to Debian users. Read the Membership section if you're interested in joining us.
If you speak a language other than English, you can contribute rightaway with translations of package descriptions at ddtp.debian.org.
When working on these, you will find immediate targets for improvements of the original English versions, too. For these, though, you need access to Debian-Med's source code repository. Very welcome are tutorials that guide Debian users towards the use of packages to their immediate benefit. You may also consider to write respective articles for Magazines, be they online or in print.
To request membership to this group, please go on our Alioth page, or directly follow this link. Remember that you must have an Alioth account before requesting membership (see here to request an Alioth account).
Our Subversion (SVN) repository is currently hosted on Alioth, the hosting facility provided by Debian to free software developers. You can have a look at the repository through Alioth's web interfaces.
To check sources out from SVN, please do:
if you are a member of Debian-Med:
svn cosvn+ssh://user@alioth.debian.org/svn/debian-med/trunk/...if you are NOT a member of Debian-Med:
svn cosvn://svn.debian.org/svn/debian-med/trunk/...
Another way to check the sources is through the use of the debcheckout command, from the devscripts package.
The SVN repository is structured as follows:
debian-med/
└ trunk/
├ community/
│ ├ debtags/
│ ├ infrastructure/
│ └ website/
└ packages/
├ <package A>/
│ ├ branches/
│ ├ tags/
│ └ trunk/
│ └ debian/
├ <package B>/
│ ├ branches/
│ ├ tags/
│ └ trunk/
│ └ debian/
…
Note
We are currently considering an alternative layout in which all
the trunk, tags and
branches directories are grouped together, so that developpers can checkout trunks without tags.
If you intent to work on a Debian package you should follow the normal Debian rules and file a WNPP bug report.
It is a good idea to keep the Debian-Med mailing list debian-med@lists.debian.org in CC or forward the response of the BTS that includes the bug number to the mailing list to keep your co-workers informed.
In addition to this you should add a user tag to this WNPP bug to make sure that your intent is in focus of the Debian-Med team.
This can be done by sending a mail to request@bugs.debian.org with the following content:
user debian-med@lists.debian.org usertag <bug-number> + wnpp med-<task> thanks
For instance if you want to tag an ITP with bug number #123456 for Debian-Med section biology you would do the following:
mailx -s "Tagging bug #123456" request@bugs.debian.org <<... user debian-med@lists.debian.org usertag 123456 + wnpp med-bio thanks ...
Section. Should be “science” for the source package.
Priority. Should be “optional” unless forbidden by the Debian policy (see section 2.5). Packages of priority “extra” are excluded from some QA tests.
Maintainer. Maintainer should be Debian-Med Packaging Team
<debian-med-packaging@lists.alioth.debian.org>. Please subscribe to this list if you list yourself in theUploaders:field of one of Debian-Med's packages. You can refer to the QA page corresponding to this email to gather information about the packages.Upload by Debian Maintainers. Should be enabled with the field
DM-Upload-Allowed: yes. This means that when an Uploader becomes Debian Maintainer, he will immediately get the possibility to upload the package to Debian. Please consider this when you sponsor packages in which some Uploaders are added.Uploaders. Please add yourelf as an uploader when you have a significant interest in a package. Being Uploader means that you are expected to answer to the bug reports. It is totally acceptable to do some QA work on a package without adding oneself to the Uploaders field.
Standards-Version. Please always use the latest unless there are concerns for backporting. If no changes are needed, please indicate this fact in the changelog, and increment the value of the field.
Homepage. should be documented whenever possible
Vcs-Svn: and Vcs-Browser: Please use the following template:
Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/<package>/trunk/ Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/<package>/trunk/?rev=0&sc=0
We use the proposed machine-readable format for the debian/copyright file. Please list yourself in the Files: debian/* section if you think that your contributions are not trivial and therefore subjected to copyright. Please chose a license that is compatible with the program you package. You can also use “same as if it were in the public domain” or “same as the packaged program itself”.
Packages hosted in our Subversion repository, that have been modified but not uploaded must use UNRELEASED as a distribution name. This can be done automatically by declaring DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts and using dch.
Debhelper uses compatibility levels to control the behaviour of its commands. The latest level is not always available in Stable or Backports. Please avoid using it unless needed until it is available, to facilitate backporting. We currently recommend to use the level 5.
The use of CDBS is welcome as it helps us to factorise our code. Nevertheless, please do not use complex CDBS for non-trivial packages, so that other developpers can quickly understand the package when doing QA work.
It is technically possible to build CDBS packages using Debhelper without the debian/compat file. Please do not, and always include such a file according to the above guidelines.
To inject a new package to the SVN repository, you must have write access to it; i.e. you must be a member of the debian-med group on Alioth.
You can inject a new package only after successfully building
it with dpkg-buildpackage (or any wrapper around it). We use the MergeWithUpstream workflow, so please keep all the modifications in the debian directory, and use the -o of svn-buildpackage, as in the following example:
svn-inject-opackage.dscsvn+ssh://user@alioth.debian.org/svn/debian-med/trunk/packages/
The svn-inject command is found in the svn-buildpackage package (just apt-get it).
Once you injected a new package please make sure that it is mentioned in the apropriate tasks file in the package source of the debian-med CDD package in SVN. Normally maintainer watch the changes in the Debian-Med packaging pool but it helps if the maintainer of a certain package verifies that everything is in the right place.
To build the package, just use the tools that svn-buildpackage carries. First of all, we suggest you to define some aliases for the most common commands:
alias svn-b='svn-buildpackage -us -uc -rfakeroot --svn-ignore' alias svn-br='svn-b --svn-dont-purge --svn-reuse' alias svn-bt='svn-buildpackage --svn-tag -rfakeroot'
Checkout the sources (see the proper section).
Once done, you're ready to do the work. First, cd to the trunk
directory, and download the upstream sources (if there is a
debian/watch file):
echo "origDir=.." >> .svn/deb-layout && uscan --force-download
Alternatively, you can try this, it depends on how the package
was built (again, from the trunk/ directory):
debian/rules get-orig-source
Once done, edit the files you need, and then build the package with svn-b or svn-br.
If you're a Debian-Med member, you can commit your changes:
svn commit
(also svn ci).
Otherwise, you can ask to be added to the group (see the Membership section), or send the result of svn diff to the mailing list (gzip -9 it, if it's too large).
It may happen that a package version has been uploaded to Debian repositories, and you forgot to tag the last build with
svn-buildpackage --svn-tag
You can tag this package also retroactively. A first step, creating the tags directory, can be achieved in two ways:
create it locally (it is a sibling of
trunk/), and commit:svn mkdirtagssvn commitcreate it remotely:
svn mkdirsvn+ssh://user@svn.debian.org/svn/debian-med/trunk/packages/<package>/tags
After the tags directory has been created, you're ready to tag the package:
svn-buildpackage --svn-tag-only --svn-no-autodch
(--svn-no-autodch avoids debian/changelog to be marked as UNRELEASED).
Often happens that the upstream code doesn't fit well into the
Debian distribution: be this wrong paths, missing features, anything
that implies editing the source files. When you directly edit
upstream's source files, your changes will be put into a .diff.gz file,
which should instead contain only debian. To better organise the patches and group the by function, please use a patch handling system which keeps patches under the
debian/patches directory.
The most known are quilt, simple-patchsys (from the CDBS package) and dpatch. Please don't use any other patch system in Debian-Med, unless absolutely necessary.
Using quilt is rather easy.
First, make sure you have correctly setup quilt: open
.quiltrc in your home directory (create
it if you don't have one), and make sure it looks like this:
QUILT_DIFF_ARGS="--no-timestamps --no-index" QUILT_REFRESH_ARGS="--no-timestamps --no-index" QUILT_PATCH_OPTS="--unified-reject-files" QUILT_PATCHES="debian/patches"
After this, you're ready to start working with quilt.
To create a patch, use the new command. Run:
quilt new<patch_name>.patch
This will create (if it doesn't exist yet) a
debian/patches/series file, which
contains all the patches to be applied by quilt. Moreover,
the new patch is also the topmost (the currently
applied).
Now start editing files, with:
quilt edit<file>
and repeat the process for each file the patch is involved with. At the end, run
quilt refresh
This will compare the noted state of the edited files
with the current state, and will produce a patch in
debian/patches. Remember: the patch
is currently applied (you can check this with
quilt applied).
Just two easy commands to do the job:
quilt pop will unapply the topmost patch.
quilt push will apply the next patch in debian/patches/series.
You can just add a "-a" flag to the commands above, to respectively apply/unapply all patches in the series.
Tip
You can check which patches are applied/unapplied with, respectively, quilt applied and quilt unapplied.
To edit a patch, first make it the topmost:
quilt push<patch_name>
If the patch is already applied, but is not the topmost, run quilt pop until it becomes the currently applied one.
You can now run quilt edit on the files you want to change, and, when you're done, quilt refresh.
Sometimes it's useful to rename a patch. Without any hassle, do:
quilt rename -P<old_name>.patch<new_name>.patch
Add in the very first part of debian/rules
(i.e. before the targets), the line:
include/usr/share/quilt/quilt.make
Please use this to import patch and unpatch rules instead of writing them, and remember to add the needed dependencies to its targets:
... build: patch build-stamp build-stamp: configure ...
This kind of dependency will ensure that if you also patch the build system, you get a working patched build process.
Caution
Don't also put configure as a dependency of build (leave it in build-stamp): that may cause problems during parallel buildings (i.e. the -j flag of make).
Now add a dependency to the clean target:
... clean: unpatch ...
If you've also patched the build system, using upstream's clean target might fail. This is what you should do:
... clean: clean-patched unpatch clean-patched: ...
Obviously, you could always use an approach like this,
but it's an useless complication if you don't patch the build
system, and you should keep debian/rules
the simplest you can.