[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#31961: marked as done (packaging-manual: editorial fixes)



Your message dated 07 May 1999 13:27:10 -0500
with message-id <871zgsenwh.fsf@glaurung.green-gryphon.com>
and subject line [Debian Installer <maor-installer@debian.org>] packaging-manual_2.5.1.0_i386.changes INSTALLED
has caused the attached bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I'm
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Ian Jackson
(administrator, Debian bugs database)

Received: (at submit) by bugs.debian.org; 16 Jan 1999 01:03:51 +0000
Received: (qmail 28197 invoked from network); 16 Jan 1999 01:03:42 -0000
Received: from mv.mv.com (root@192.80.84.1)
  by master.debian.org with SMTP; 16 Jan 1999 01:03:42 -0000
Received: from vanzandt.mv.com (root@vanzandt.mv.com [207.22.43.76]) by mv.mv.com (8.8.8/mem-971025) with ESMTP id UAA18455 for <submit@bugs.debian.org>; Fri, 15 Jan 1999 20:03:33 -0500 (EST)
Received: by vanzandt.mv.com
	via sendmail with stdio
	id <m101GTL-0006NFC@vanzandt.mv.com> (Debian Smail3.2.0.101)
	for submit@bugs.debian.org; Fri, 15 Jan 1999 16:08:03 -0500 (EST) 
Message-Id: <m101GTL-0006NFC@vanzandt.mv.com>
Date: Fri, 15 Jan 1999 16:08:03 -0500 (EST)
From: <jrv@vanzandt.mv.com>
Subject: packaging-manual: editorial fixes
To: submit@bugs.debian.org
X-Mailer: bug 3.1.6.1

Package: packaging-manual
Version: 2.5.0.0

I suggest these changes:

--- packaging.sgml.orig	Fri Jan 15 15:35:20 1999
+++ packaging.sgml	Fri Jan 15 16:05:28 1999
@@ -118,7 +118,7 @@
 	This manual describes the technical aspects of creating Debian
 	binary packages (<tt>.deb</tt> files).  It documents the
 	behaviour of the package management programs
-	<prgn>dpkg</prgn>, <prgn>dselect</prgn> et al. and and the way
+	<prgn>dpkg</prgn>, <prgn>dselect</prgn> et al. and the way
 	they interact with packages.</p>
 
       <p>
@@ -2711,7 +2711,7 @@
 	</heading>
 
 	<p>	  
-	  It is possible supply scripts as part of a package which
+	  It is possible to supply scripts as part of a package which
 	  <prgn>dpkg</prgn> will run for you when your package is
 	  installed, upgraded or removed.
 	</p>
@@ -3527,7 +3527,7 @@
       </sect>
 
       <sect><heading>Dependencies - <tt>Depends</tt>, <tt>Recommends</tt>,
-	  <tt>tt>Sugge</tt>tt>, <tt>Pre-Depends</tt>
+	  <tt>Suggests</tt>, <tt>Pre-Depends</tt>
 	</heading>
 
 	<p>	  
@@ -3765,7 +3765,7 @@
       </sect1>
 
       <sect id="conflicts"><heading>Alternative packages -
-	  <tt>tt>Confli</tt>tt> and <tt>Replaces</tt>
+	  <tt>Conflicts</tt> and <tt>Replaces</tt>
 	</heading>
 
 	<p>	  
@@ -3840,7 +3840,7 @@
 	  <tt>Provides</tt> control file field of another package.
 	  The effect is as if the package(s) which provide a
 	  particular virtual package name had been listed by name
-	  everywhere were the virtual package name appears.
+	  everywhere the virtual package name appears.
 	</p>
 
 	<p>	  
@@ -3886,7 +3886,7 @@
 	<p>	  
 	  If you want to specify which of a set of real packages should be the
 	  default to satisfy a particular dependency on a virtual package, you
-	  should list the real package as alternative before the virtual.
+	  should list the real package as an alternative before the virtual.
 	</p>
       </sect>
 	
@@ -3960,7 +3960,7 @@
 	  <p>	    
 	    Secondly, <tt>Replaces</tt> allows <prgn>dpkg</prgn> and
 	    <prgn>dselect</prgn> to resolve which package should be
-	    removed when a conflict - see <ref id="conflicts">.  This
+	    removed when there is a conflict - see <ref id="conflicts">.  This
 	    usage only takes effect when the two packages <em>do</em>
 	    conflict, so that the two effects do not interfere with
 	    each other.
@@ -4092,7 +4092,7 @@
 	<p>	  
 	  If neither the user nor the package maintainer has changed
 	  the file, it is left alone.  If one or the other has changed
-	  their version, then the changed version is preferred - ie,
+	  their version, then the changed version is preferred - i.e.,
 	  if the user edits their file, but the package maintainer
 	  doesn't ship a different version, the user's changes will
 	  stay, silently, but if the maintainer ships a new version


-- System Information
Debian Release: 2.0
Kernel Version: Linux vanzandt 2.1.132 #5 Tue Dec 29 15:31:03 EST 1998 i686 unknown


Reply to: