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

Bug#504880: Disambiguate "installed" for packages



Package: debian-policy
Version: 3.8.0.1
Severity: wishlist

The policy manual currently uses the word "installed" in a couple of
different ways when referring to packages. Sometimes it's speaking quite
loosely, and in this sense is talking about something roughly equivalent
to 'dpkg --install'. However, in some other cases it's using a sense of
the word which I believe derives from dpkg's internal state machine, and
which corresponds to 'dpkg --unpack'. On quite a number of occasions
I've helped to explain this to people who were confused as a result: for
instance, unless you realise the second sense, the definition of
Conflicts is quite difficult to read.

I suggest that the second sense should be written as "unpacked" rather
than "installed". Although this breaks the correspondence with dpkg's
internal state machine, it brings the policy manual into line with the
verbs used on dpkg's command line, which I think correspond much more
reliably to how people think of the operation or state in question.

I've attached a patch, and am seeking seconds for this proposal. Please
double-check it for correctness, particularly the change in the
definition of Breaks; I have only verified that against an old mail from
Ian proposing the design of this field
(http://lists.debian.org/debian-devel/1997/10/msg00643.html), not
against the current implementation.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]
diff --git a/policy.sgml b/policy.sgml
index 7de382d..44ff374 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1034,8 +1034,8 @@
 	</p>
 
 	<p>
-	  Sometimes, a package requires another package to be installed
-	  <em>and</em> configured before it can be installed. In this
+	  Sometimes, a package requires another package to be unpacked
+	  <em>and</em> configured before it can be unpacked. In this
 	  case, you must specify a <tt>Pre-Depends</tt> entry for
 	  the package.
 	</p>
@@ -3456,7 +3456,7 @@ Package: libc6
 
 	<p>
 	  Broadly speaking the <prgn>preinst</prgn> is called before
-	  (a particular version of) a package is installed, and the
+	  (a particular version of) a package is unpacked, and the
 	  <prgn>postinst</prgn> afterwards; the <prgn>prerm</prgn>
 	  before (a version of) a package is removed and the
 	  <prgn>postrm</prgn> afterwards.
@@ -3835,7 +3835,7 @@ Package: libc6
 		behavior which, though deterministic, is hard for the
 		system administrator to understand.  It can easily
 		lead to "missing" programs if, for example, a package
-		is installed which overwrites a file from another
+		is unpacked which overwrites a file from another
 		package, and is then removed again.<footnote>
 		    Part of the problem is due to what is arguably a
 		    bug in <prgn>dpkg</prgn>.
@@ -3971,7 +3971,7 @@ Package: libc6
 		If there was a conflicting package we go and do the
 		removal actions (described below), starting with the
 		removal of the conflicting package's files (any that
-		are also in the package being installed have already
+		are also in the package being unpacked have already
 		been removed from the conflicting package's file list,
 		and so do not get removed now).
 	    </item>
@@ -4413,7 +4413,7 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
 	<p>
 	  When one binary package declares that it breaks another,
 	  <prgn>dpkg</prgn> will refuse to allow the package which
-	  declares <tt>Breaks</tt> be installed unless the broken
+	  declares <tt>Breaks</tt> be unpacked unless the broken
 	  package is deconfigured first, and it will refuse to
 	  allow the broken package to be reconfigured.
 	</p>
@@ -4454,13 +4454,13 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
 	<p>
           When one binary package declares a conflict with another
 	  using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
-	  refuse to allow them to be installed on the system at the
+	  refuse to allow them to be unpacked on the system at the
 	  same time.
 	</p>
 
 	<p>
-	  If one package is to be installed, the other must be removed
-	  first - if the package being installed is marked as
+	  If one package is to be unpacked, the other must be removed
+	  first - if the package being unpacked is marked as
 	  replacing (see <ref id="replaces">) the one on the system,
 	  or the one on the system is marked as deselected, or both
 	  packages are marked <tt>Essential</tt>, then
@@ -4655,7 +4655,7 @@ Provides: mail-transport-agent
 Conflicts: mail-transport-agent
 Replaces: mail-transport-agent
 	    </example>
-	    ensuring that only one MTA can be installed at any one
+	    ensuring that only one MTA can be unpacked at any one
 	    time.
 	</sect1>
       </sect>
@@ -4887,7 +4887,7 @@ Replaces: mail-transport-agent
          <footnote>
 	    <p>
 	      During install or upgrade, the preinst is called before
-	      the new files are installed, so calling "ldconfig" is
+	      the new files are unpacked, so calling "ldconfig" is
 	      pointless.  The preinst of an existing package can also be
 	      called if an upgrade fails.  However, this happens during
 	      the critical time when a shared libs may exist on-disk
@@ -5023,7 +5023,7 @@ Replaces: mail-transport-agent
 	<ref id="conflicts">) to ensure that the user only installs one
 	development version at a time (as different development versions are
 	likely to have the same header files in them, which would cause a
-	filename clash if both were installed).
+	filename clash if both were unpacked).
       </p>
 
       <p>
@@ -9267,7 +9267,7 @@ install-info --quiet --remove /usr/share/info/foobar.info
 	<p>
 	  The <prgn>DEBIAN</prgn> directory will not appear in the
 	  file system archive of the package, and so won't be installed
-	  by <prgn>dpkg</prgn> when the package is installed.
+	  by <prgn>dpkg</prgn> when the package is unpacked.
 	</p>
 
 	<p>

Reply to: