This has the following advantages:
.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:
Format
Date
Source
Binary
Architecture
Version
Distribution
Urgency
Maintainer
Description
Changes
Files
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.
/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.
/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.
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.
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.
.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.
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.
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.