Update preferred contact method for the security team.

[developers-reference.git] / best-pkging-practices.dbk

diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 575a80fc3f9e7d66a799e7d210a53de0b6985671..30afaf2b47567d7bd891e3bdb63e81b90e73ca7c 100644 (file)
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -75,13 +75,6 @@ individual <command>dh_*</command> helpers.  If you are going to use a helper,
 you do need to take the time to learn to use that helper, to learn its
 expectations and behavior.
 </para>
-<para>
-Some people feel that vanilla <filename>debian/rules</filename> files are
-better, since you don't have to learn the intricacies of any helper system.
-This decision is completely up to you.  Use what works for you.  Many examples
-of vanilla <filename>debian/rules</filename> files are available at <ulink
-url="&url-rules-files;"></ulink>.
-</para>
 </section>
 
 <section id="multiple-patches">
@@ -1630,9 +1623,9 @@ incrementing the version number, so there can be no guarantee that a pristine
 tarball is identical to what upstream <emphasis>currently</emphasis>
 distributing at any point in time.  All that can be expected is that it is
 identical to something that upstream once <emphasis>did</emphasis> distribute.
-If a difference arises later (say, if upstream notices that he wasn't using
-maximal compression in his original distribution and then
-re-<command>gzip</command>s it), that's just too bad.  Since there is no good
+If a difference arises later (say, if upstream notice that they weren't using
+maximal compression in their original distribution and then
+re-<command>gzip</command> it), that's just too bad.  Since there is no good
 way to upload a new <filename>.orig.tar.{gz,bz2,xz}</filename> for the same version, there is not even any
 point in treating this situation as a bug.  </para> </footnote> This makes it
 possible to use checksums to easily verify that all changes between Debian's
@@ -1688,7 +1681,7 @@ that you must remove before uploading.
 </para>
 <para>
 In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,xz}</filename>
-file himself.  We refer to such a tarball as a repackaged upstream 
+file themselves.  We refer to such a tarball as a repackaged upstream
 source.  Note that a repackaged upstream source is different from a 
 Debian-native package.  A repackaged source still comes with Debian-specific
 changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,xz}</filename>
@@ -1856,7 +1849,7 @@ of meta-packages (built by the source packages
 </para>
 <para>
 The long description of the meta-package must clearly document its purpose
-so that the user knows what he will lose if he removes the package. Being
+so that the user knows what they will lose if they remove the package. Being
 explicit about the consequences is recommended. This is particularly
 important for meta-packages which are installed during initial
 installation and that have not been explicitly installed by the user.