[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
There are few chores you should know to check the package for errors by yourself before uploading packages to public archives.
Testing on machine other than your own is also good idea. You must watch closely for any warnings or errors for all the test described here.
You must test your package if it installs without problem. The
debi(1)
command helps you to test to install all the generated
binary packages.
$ sudo debi gentoo_0.9.12-1_i386.changes
You have to make sure that there are no overlapped files with other existing
packages using the Contents-i386
file downloaded from
the Debian archive to prevent installation problem on different systems. The
apt-file
command may be handy for this task. If there are
overlapped files, please take actions to avoid the real problem using the
alternatives mechanism (see update-alternatives(1)
) by
coordinating with other affected packages or by setting the
"Conflicts" entry in the debian/control
file.
All maintainer scripts, i.e., preinst
,
prerm
, postinst
, and postrm
files, are
non-trivial unless they are auto-generated by the debhelper
programs. So do not use them if you are a novice maintainer (see {post|pre}{inst|rm}
files,
Section 5.18).
If the package makes use of these non-trivial maintainer scripts, be
sure to test not only for install but also for remove, purge, and upgrade.
Many maintainer script bugs show up when packages are removed or
purged. Use the dpkg
command as follows to test them.
$ sudo dpkg -r gentoo $ sudo dpkg -P gentoo $ sudo dpkg -i gentoo_version-revision_i386.deb
This should be done with sequences such as the following.
install the previous version (if needed).
upgrade it from the previous version.
downgrade it back to the previous version (optional).
purge it.
install the new package.
remove it.
install it again.
purge it.
If this is your first package, you should create dummy packages with different versions to test your package in advance to prevent future problems.
Bear in mind that if your package has previously been released in Debian, people will often be upgrading to your package from the version that was in the last Debian release. Remember to test upgrades from that version too.
Although downgrade is not officially supported, it should be nice to support it.
lintian
package
Run lintian(1)
on your .changes
file. The
lintian
command runs many test scripts to check for many common
packaging errors. [50]
$ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes
Of course, replace the filename with the name of the .changes
file
generated for your package. The output of the lintian
command are
marked as follows.
E: for error; a sure policy violation or a packaging error.
W: for warning; a possible policy violation or a packaging error.
I: for info; a information on certain packaging aspects.
N: for note; a detailed message to help your debugging.
O: for overridden; a message overridden by the
lintian-overrides
files but displayed by the
--show-overrides option.
For warnings, tune the package to avoid them or verify that the warnings are
spurious. If spurious, set the lintian-overrides
files as
described in {package.|source/}lintian-overrides
files, Section 5.13.
Note that you can build the package with dpkg-buildpackage
and run
lintian
on it in one command with debuild(1)
or with
pdebuild(1)
.
debc
command
You can list files in the binary Debian package by debc(1)
command.
$ debc package.changes
debdiff
command
You can compare file contents in two source Debian packages with the
debdiff(1)
command.
$ debdiff old-package.dsc new-package.dsc
You can also compare file lists in two sets of binary Debian packages with the
debdiff(1)
command.
$ debdiff old-package.changes new-package.changes
These are useful to identify what has been changed in the source packages, if no files have been unintentionally misplaced or removed in the binary packages, and if no other inadvertent changes were made when updating binary packages.
interdiff
command
You can compare two diff.gz
files with the
interdiff(1)
command. This is useful for verifying that no
inadvertent changes were made to the source by the maintainer when updating
packages in the old 1.0 source format.
$ interdiff -z old-package.diff.gz new-package.diff.gz
mc
command
Many of these file inspection operations can be made into an intuitive process
by using a file manager like mc(1)
which will let you browse not
only the contents of *.deb
package files but also
*.udeb
, *.debian.tar.gz
, *.diff.gz
, and
*.orig.tar.gz
files.
Be on the lookout for extra unneeded files or zero length files, both in the
binary and source package. Often cruft doesn't get cleaned up properly; adjust
your rules
file to compensate for that.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]
Debian New Maintainers' Guide
version 1.2.25, 2010-12-22 12:44:34 UTCjoy-mg@debian.org