Differences between revisions 8 and 9
Revision 8 as of 2012-09-28 09:41:37
Size: 5128
Editor: PaulWise
Comment: upstream guide
Revision 9 as of 2012-10-10 14:24:20
Size: 5168
Editor: LaszloKajan
Comment: minimal rewording
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
They could search google. The Debian packages would show up among the results. There also are listings for example at [[http://debian-med.alioth.debian.org/tasks/bio|bio]] and [[http://debian-med.alioth.debian.org/tasks/bio-dev|bio-dev]], where all included packages (and even those we would like to include), appear, with description and references. They could search the net. The Debian packages would show up among the results. There also are listings for example at [[http://debian-med.alioth.debian.org/tasks/bio|bio]] and [[http://debian-med.alioth.debian.org/tasks/bio-dev|bio-dev]], where all included packages (and even those we would like to include), appear, with description and references.
Line 22: Line 22:

... it comes with no documentation.

Translation(s): none


This page is to help answer questions of upstream authors to Debian maintainers wishing to package their software.

Who uses Debian?

For example people who care about stable software (stable also in the sense that it does not change often).

A listing is here:

In addition to this, Debian packages are readily available in Debian-based distributions like Ubuntu or Linux Mint. When something is packaged for Debian, it also is available for Ubuntu and Mint. There also is Bio-Linux that is based on Ubuntu, and so Debian packages are also available there. Andreas Tille says http://www.embl.fr/ also uses Debian.

How would users find out about my software?

They could search the net. The Debian packages would show up among the results. There also are listings for example at bio and bio-dev, where all included packages (and even those we would like to include), appear, with description and references.

How would they learn how to use my software?

... it comes with no documentation.

Some can just read the code. A program using your library automatically provides usage examples. Often some doxygen documentation can be generated easily for libraries, giving a nice overview. But sure, extra human-written documentation is good to have.

What are the advantages of distributing code via Debian?

... rather than putting a zip file on a simple web page (like how most research code is distributed)?

For one, when the code comes from a package, users (students) are less inclined to make (as files are owned by root) ad-hoc modifications to it, generating private versions (which may lead to nightmare when you fix bugs in your version). Also, much less knowledge (about the details of building a library (e.g. hardening the code) is required to obtain the code. Dependencies, also, are automatically satisfied, in case not all of them are bundled with the zip file. It saves time for admins to install from packages and it allows other packaged software to depend on yours and be easily installable. This is nice when you build an image for cloud computing, for example.

Why do you want to put the code in Debian rather than just use it yourself?

I have been using packages of all sorts as a Linux user, and was wondering where those come from. Now, as a Debian Maintainer, I can see that they come from people who find them useful, and package them. I am now at the point where I also can contribute packages, and so I do. It is not entirely altruistic, either. We manage our local cluster, and other computers in clouds, through Debian packages. This simplifies matters a lot. We just make sure the same packages (or a convenient metapackage) are installed, the package manager keeps everything up-to-date. I do not have to worry about getting all I need accessible everywhere though some share NFS or other. I just install the packages I need.

I am worried about the idea of other people fixing bugs, writing new functions, etc.

... as this would create different versions of my software, cause confusion, and in my opinion decrease its stability.

Regarding your worry about people writing new functions: this is something we really try to avoid when doing the packaging.

I am worried about Debian shipping an old (and buggy) version for a long time

If a new version that fixes the bug is available, then it should be published. There is a watch mechanism in the debian packaging framework that allows to specify where new versions of the packaged software can be found. By providing a detailed url of that location, the uscan program can check for new versions of the software. The debian packager should run uscan regularly in order to assess if a new version is available or not. This watch mechanism emphasizes the importance of always publishing new software versions with a version numbering that sticks to one precise scheme (like version <softname>-1.2.3 should be followed by something analogous, version <softname>-1.3.5, for example). Anyway, in general, it is the task of the Debian packager to ensure that a new version of the software is available in Debian. If, for some reason, that is not the case, it is always possible to file a bug report against the package stating that it is a wish for a new software version to be packaged (this is done by indicating a severity "wishlist" for the bug). Of course, you are also welcome to e-mail the Debian maintainer of your package (search '<yourpackage> debian maintainer') and make him aware of the new version.

What should I do to make my software more friendly to Debian and other distros?

Please take a look at our upstream guide and the links at the bottom of it.