Debian Developer's Reference - chapter 4
Package uploads


4.1 Announcing new packages

If you want to create a new package for the Debian distribution, you have to send a short email to debian-devel describing your plans before you upload the new package.

This has the following advantages:


4.2 Uploading a package


4.2.1 Generating the changes file

When a package is uploaded to the Debian FTP archive, it must be accompanied by a .changes file which gives directions for its handling. This is usually generated by dpkg-genchanges.

This file is a control file with the following fields:

All of them are mandatory for a Debian upload. See the list of control fields in the Debian Packaging Manual for the contents of these fields.

The first time a version is uploaded which corresponds to a particular upstream version the original source tar file should be uploaded and included in the .changes file; subsequent times the very same tar file should be used to build the new diffs and .dsc files, and it need not then be uploaded.

By default dpkg-genchanges and dpkg-buildpackage will include the original source tar-file if and only if the Debian revision part of the source version number is 0 or 1, indicating a new upstream version. This behaviour may be modified by using -sa to always include it or -sd to always leave it out.

If no original source is included in the upload then the original source tar-file used by dpkg-source when constructing the .dsc file and diff to be uploaded must be byte-for-byte identical with the one already in the archive. If there is some reason why this is not the case then the new version of the original source should be uploaded, possibly by using the -sa flag.


4.2.2 Transferring the files to master

To upload a package, you need a personal account on the master server. Just log in via ftp and transfer the files to `/home/Debian/ftp/private/project/Incoming.' (You cannot upload to Incoming on master using anonymous FTP--you must use your user-name and password.)

You may also find the Debian package 'dupload' useful in uploading new packages to master. See the 'dupload' documentation for more information.


4.2.3 Uploads via Chiark

If you have a slow network connection to the master system, there are two alternatives: You can upload files to Incoming via a cron-driven upload queue in Europe on ftp.chiark.greenend.org.uk. For details connect to chiark using anonymous FTP and read /pub/debian/private/project/README.how-to-upload.

The program dupload support uploads to chiark, please refer to the documentation that comes with the program, for details.


4.2.4 Uploads via Erlangen

Another cron-driven upload queue is available in Germany: Just upload the files via anonymous FTP to ftp://ftp.uni-erlangen.de/pub/Linux/debian/UploadQueue.

The upload must be a complete Debian upload, as you would put it into master's incoming, i.e. a .changes files along with the other files mentioned in the .changes. The queue daemon also checks that the .changes is correctly PGP-signed by a Debian developer, so that no bogus files can find their way to master via the queue. Please also make sure that the Maintainer: field in the .changes contains *your* e-mail address. The address found there is used for all replies, just as on master.

There's no need to move your files into a second directory after the upload as on chiark. And, in any case, you should get some mail reply from the queue daemon what happened to your upload. Hopefully it should have been moved to master, but in case of errors you're notified, too.

The program dupload support uploads to erlangen, please refer to the documentation that comes with the program, for details.


4.2.5 Uploading to the non-us server

To upload a package to the non-us server you just have to transfer the files via anonymous ftp to ftp://nonus.debian.org/pub/debian-non-US/Incoming. Note, that the .changes file must have a valid PGP signature from one of the keys of the developers keyring.


4.3 Announcing package uploads

When a package is uploaded an announcement should be posted to one of the debian-changes lists. The announcement should give the (source) package name and version number, and a very short summary of the changes, in the Subject field, and should contain the PGP-signed .changes file. Some additional explanatory text may be added before the start of the .changes file.

If a package is released with the Distribution: set to stable, the announcement is sent to debian-changes@lists.debian.org.

If a package is released with Distribution: set to unstable, experimental, or frozen (when present), the announcement should be posted to debian-devel-changes@lists.debian.org instead.


4.4 Interim releases

Under certain circumstances it is necessary for someone other than the usual package maintainer to make a release of a package. For example, a porter for another architecture may have to make some small changes to the source package and does not wish to wait with uploading their release until the main maintainer has incorporated the patch, or a serious security problem may have come to light requiring immediate attention.

When a security bug is detected a fixed package should be uploaded as soon as possible. In this case, the Debian Security Managers should get in contact with the package maintainer to make sure a fixed package is uploaded within a reasonable time (less than 48 hours). If the package maintainer cannot provide a fixed package fast enough or if he/she cannot be reached in time, the Security Manager may upload a fixed package.

When someone other than the usual maintainer releases a package they should add a new component to the debian-revision component of the version number--that is, the portion after the (last) hyphen. This extra component will start at 1. This is to avoid `stealing' one of the usual maintainer's version numbers, possibly disrupting their work. If there is no debian-revision component in the version number then one should be created, starting at 1.

If it is absolutely necessary for someone other than the usual maintainer to make a release based on a new upstream version then the person making the release should start with the debian-revision value 0.1. The usual maintainer of a package should start their debian-revision numbering at 1.

Maintainers other than the usual package maintainer should make as few changes to the package as possible, and they should always send a unified context diff (diff -u) detailing their changes to the bug tracking system properly flagged with the correct package so that the usual maintainer is kept aware of the situation. If the non-maintainer upload fixes some bugs, the bug reports should not be closed. However, the person making the non-maintainer release should send a short message to the bug tracking system to all the fixed bugs explaining that they have been fixed. This way, the maintainer and other people will get notified about that.

The normal maintainer should do at least one of

In addition, the normal maintainer should always include an entry in the changelog file documenting the non-maintainer upload.


4.5 Maintainer changes

Periodically, a listing of packages in need of new maintainers will be sent to the debian-devel list. This list is also available at ftp.debian.org in /debian/doc/package-developer/prospective-packages.html If you wish to take over maintenance of any of those packages, or if you can no longer maintain the packages you have, or you simply want to know if any one is working on a new package, send a message to override-change@debian.org.

If you take over an old package, you probably want to be listed as the package's official maintainer in the bug system. This will happen automatically once you upload a new version with an updated Maintainer: field. If you do not expect to upload a new version for a while, send an email to override-change@debian.org so that bug reports will go to you.


Debian Developer's Reference - Copyright ©1997,1998 Christian Schwarz.
Contents; next; back.
version 2.4.1.2, 14 April 1998
Christian Schwarz schwarz@debian.org
based on earlier documents by Ian Jackson ijackson@gnu.ai.mit.edu