This page contains my (personal) tips and tricks for mentees so that they get the upload of their packages into the Debian archive sponsored by me.
If you’re interested in having me as sponsor for some of your packages, I’d be happy if you would have a look at this page and try to follow these requirements, recommendations and suggestions.
Contact me on IRC (XTaran on OFTC, Freenode, (German) IRCNet, LUGS IRC Network, Chaostreff.ch IRC Network, …), by e-mail (email@example.com) or in real life.
Packages uploaded to Debian should have successive Debian versions. Especially packages containing new upstream versions should end in either a
-1 or lower (e.g. for NMUs or upload to experimental).
-1~dev1in case you prefer to upload only distinct versions to mentors.debian.net. Nevertheless do merge their changelogs for the final version.
~based suffix for versions in those repositories is appreciated, though.
licensecheckfrom the devscripts package. Does it show anything unexpected? Are all found licenses DFSG-compliant?
lintian -L '>=pedantic/wild-guess'on the
.changesfile or instruct
debuildto do so automatically.
lintian-infoor add the
blhcfrom the blhc package.
debdiffover the previous and the current source packages. Anything unexpected?
debdiffover all binary packages of the previous and the current source packages. Anything unexpected?
nocheck? (Or just use
dh_auto_testand no more care about the correct usage of the test suite. :-)
… and you should, too. ;-)
cleantarget should restore the source package into the same state as it was at unpack time. Having the package in VCS helps here.
config.subat build-time, i.e. build-depend on autotools-dev (either directly or indirectly via dh-autoreconf)
config.submanually in the
debian/rulesfile unless you have a very good reason for not using
dh_cleanand debhelper compatibility level 7 or higher.
debiandirectory should be documented in the package’s changelog. Details may be left out on bigger changes which obviously change those things not mentioned.
Standard-Versionor the debhelper compatibility level, always mention to which level you switch.
Dependsshould be real hard dependencies. All optional dependencies go either into
Suggests, even if there are people which are annoyed because their use-case didn’t work out-of-the-box, because they disabled pulling in recommended packages by default.
dpkg’s build flags, i.e. hardening flags. Using
dh_auto_buildand debhelper compatibility ≥ 9 often helps already a lot here.
pythonand/or binary package prefix
python-if you’re packaging a python-written application or service.
rubyand/or binary package prefix
ruby-if you’re packaging a ruby-written application or service.
perland/or a binary package name of the scheme
lib*-perlif you’re packaging a perl-written application or service.
dpkgis picky at that point :-)
README.sourcedocumenting why and how the upstream tar-ball has been repackaged.
debian/ruleswhich does repackaging (and optionally the downloading, too)
LICENSEdoes not count. Upstream may have copied some code from other sources and did not mention it in their documentation.
(Applies if I already agreed to sponsor your packages.)
-us -ucor use
.dscfiles, but a pointer to some VCS is fine, too, if that VCS also provides the upstream tar-balls via pristine-tar, preferably imported with
git-import-origfrom the git-buildpackage package.
This is a list of things which I prefer, so I tend to sponsor a package more likely if fits into these preferences.
debian/rulesfiles, i.e. as much as possible is done via defaults and like needs less maintenance when the defaults change in the future.
dpatchover direct changes in the Debian
Thanks to Paul Tagliamonte for inspiring this document with his Sponsoring Guildines.
Generated with Pandoc’s Markdown plugin.