chiark / gitweb /
another sentence to clarify it further
[developers-reference.git] / developers-reference.sgml
index e0c4089c8b99294fbae48fa7b22ccc95a352c229..1a90106b878eb407169ca059c4b12efdf9047ef7 100644 (file)
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.167 $">
+  <!entity cvs-rev "$Revision: 1.170 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -1796,8 +1796,8 @@ or priority for your package be changed from the old section or
 priority to the new one.  Be sure to explain your reasoning.
          <p>
 For more information about <em>override files</em>, see <manref
-name="dpkg-scanpackages" section="8">, &file-bts-mailing;, and
-&file-bts-info;.
+name="dpkg-scanpackages" section="8"> and
+<url id="&url-bts-devel;#maintincorrect">.
        <p>
 Note also that the term "section" is used for the separation of packages
 according to their licensing, e.g. <em>main</em>, <em>contrib</em> and
@@ -1986,6 +1986,8 @@ Bear in mind that it is not obligatory to close bugs using the changelog
 like described above -- if you simply want to close bugs that don't have
 anything to do with an upload of yours, do it simply by emailing an
 explanation to <email>XXX-done@bugs.debian.org</email>.
+Do <strong>not</strong> close bugs in the changelog entry of a version
+if the said version of the package doesn't have anything to do with the bug.
 
       <sect1 id="bug-security">Handling security-related bugs
         <p>
@@ -3348,7 +3350,6 @@ Lisp packages should register themselves with
 &file-lisp-controller;.
 </list>
         </sect1>
-      </sect>
 
 <!--
        <sect1 id="custom-config-files">Custom configuration files
@@ -3365,7 +3366,25 @@ Lisp packages should register themselves with
        sympa may be an example package
 -->    
 
+       <sect1 id="bpp-archindepdata">Architecture-independent data
+       <p>
+       It is not uncommon to have a large amount of architecture-independent
+       data packaged with a program. For example, collection of icons,
+       wallpapers or other graphic files, or audio files. If the size of
+       this data is negligible compared to the size of the remainder of the
+       package, you can keep it all in the same package.
 
+       <p>
+       However, if the size of the data is considerable, consider splitting
+       it out into a separate, architecture-independent package
+       ("_all.deb"). By doing this, you avoid needless duplication of the
+       same data into eleven or more .debs per each architecture. While
+       this adds some extra overhead into the Packages files, it can save a
+       lot of disk space on Debian mirrors, and it also reduces processing
+       time of Lintian or Linda when run over the entire Debian archive. 
+       </sect1>
+
+      </sect>
 
 
   <chapt id="beyond-pkging">