+<itemizedlist>
+<listitem>
+<para>Verify that the upstream tarball provided is the same that has been
+distributed by the upstream author (when the sources are repackaged for
+Debian, generate the modified tarball yourself).</para>
+</listitem>
+<listitem>
+<para>Run <command>lintian</command> (see <xref linkend="lintian"/>). It will catch many common
+problems. Be sure to verify that any <command>lintian</command> overrides setup by the
+maintainer is fully justified.</para>
+</listitem>
+<listitem>
+<para>Run <command>licensecheck</command> (part of <xref linkend="devscripts"/>) and verify that
+<filename>debian/copyright</filename> seems correct and complete. Look for
+license problems (like files with “All rights reserved”
+headers, or with a non-DFSG compliant license). <command>grep -ri</command>
+is your friend for this task.</para>
+</listitem>
+<listitem>
+<para>Build the package with <command>pbuilder</command> (or any similar tool, see <xref
+linkend="pbuilder"/>) to ensure that the build-dependencies are
+complete.</para>
+</listitem>
+<listitem>
+<para>Proofread <filename>debian/control</filename>: does it follow the
+best practices (see <xref linkend="bpp-debian-control"/>)? Are the dependencies
+complete?</para>
+</listitem>
+<listitem>
+<para>Proofread <filename>debian/rules</filename>: does it follow the
+best practices (see <xref linkend="bpp-debian-rules"/>)? Do you see some
+possible improvements?</para>
+</listitem>
+<listitem>
+<para>Proofread the maintainer scripts (<filename>preinst</filename>,
+<filename>postinst</filename>, <filename>prerm</filename>,
+<filename>postrm</filename>, <filename>config</filename>): will the
+<filename>preinst</filename>/<filename>postrm</filename> work when the dependencies are not
+installed? Are all the scripts idempotent (i.e. can you run them multiple
+times without consequences)?</para>
+</listitem>
+<listitem>
+<para>Review any change to upstream files (either in <filename>.diff.gz</filename>, or in
+<filename>debian/patches/</filename> or directly embedded in the <filename>debian</filename>
+tarball for binary files). Are they justified? Are they properly
+documented (with <ulink url="&url-dep3;">DEP-3</ulink> for patches)?</para>
+</listitem>
+<listitem>
+<para>For every file, ask yourself why the file is there and whether it's
+the right way to achieve the desired result. Is the maintainer following
+the best packaging practices (see <xref
+linkend="best-pkging-practices"/>)?</para>
+</listitem>
+<listitem>
+<para>Build the packages, install them and try the software. Ensure you can
+remove and purge the packages. Maybe test them with <command>piuparts</command>.
+</para>
+</listitem>
+</itemizedlist>
+<para>
+If the audit did not reveal any problem, you can build the package and
+upload it to Debian. Remember that even if you're not the maintainer,
+as a sponsor you are still responsible for what you upload to Debian. That's
+why you're encouraged to keep up with the package through the
+<xref linkend="pkg-tracking-system"/>.
+</para>
+<para>
+Note that you should not need to modify the source package to put your name
+in the <filename>changelog</filename> or in the <filename>control</filename> file. The <literal>Maintainer</literal>
+field of the <filename>control</filename> file and the
+<filename>changelog</filename> should list the person who did the
+packaging, i.e. the sponsoree. That way they will get all the BTS mail.
+</para>
+<para>Instead you should instruct <command>dpkg-buildpackage</command> to use your key for
+the signature. You do that with the <literal>-k</literal> option:</para>
~ianmdlvl / developers-reference.git / blobdiff