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

Bug#60461: debian-policy: FHS conformance not explicit



Package: debian-policy
Version: 3.1.1.1
Severity: normal

The current policy document does not make explicit that packages ought
to aim to be "compatible" with FHS, rather than "compliant".

Furthermore, the policy does not make explicit *which version* of FHS 
one ought to follow.  There is a passing reference to the fact that 
a pre-release FHS is included in the policy document, but I believe
this information should be made more explicit.  (When people have to
guess at what a policy document means, trouble is likely)

I am appending a diff containing my best shot at clarifying these
issues.

When I brought this issue up on debian-policy, Chris Waters suggested
that I point out the fact that current policy actively prevents packages
from being "FHS compliant" (a higher level of conformance than mere 
"compatibility").  I have included a few lines about this in the actual
policy document, because it is important for new developers to 
understand some of the rationale for settling on "mere" compatibility.


-- System Information
Debian Release: 2.2
Kernel Version: Linux riemann 2.2.13 #1 Sat Dec 4 21:48:34 EST 1999 i686 unknown

--- policy.sgml.orig	Wed Mar 15 12:18:02 2000
+++ policy.sgml	Wed Mar 15 12:23:25 2000
@@ -1085,9 +1085,17 @@
 	  <heading>Linux File system Structure</heading>
 	    
 	  <p>
-	    The location of all installed files and directories must
-	    comply  with the Linux File system Hierarchy Standard
-	    (FHS).  The latest version of this document can be found
+	    Debian packages must be <em>fully compatible</em> with the
+	    Filesystem Hierarchy Standard (FHS).  See the FHS document
+	    for a precise definition of the term <em>fully
+	    compatible</em>.  Specific questions about following the
+	    standard may be asked on <prgn>debian-devel</prgn>, or
+	    referred to Daniel Quinlan, the FHS coordinator, at
+	    <email>quinlan@pathname.com</email>.</p>
+
+	  <p>
+	    To comply with current policy, a package must be compatible
+	    with FHS Version pre-2.1 #2.  This document can be found
 	    alongside this manual or on
 	    <url id="http://www.pathname.com/fhs/";>.<footnote>
 	      <p>The Debian distribution currently distributes a draft
@@ -1095,20 +1103,39 @@
 		have changed between the currently released 2.0
 		version and the to-be-released 2.1 version.</p>
 	    </footnote>
-	    Specific questions about following the standard may be
-	    asked on <prgn>debian-devel</prgn>, or referred to Daniel
-	    Quinlan, the FHS coordinator, at
-	    <email>quinlan@pathname.com</email>.</p></sect1>
+
+	  <p>
+	    In the FHS document, <em>compatibility</em> is the lesser
+	    of two levels of conformance; systems that follow the FHS
+	    more strictly are said to be <em>fully compliant</em>.
+	    Being compliant is a worthy goal, and packagers should
+	    strive for it, as much as possible.  Current policy
+	    prevents most packages from being compliant with the FHS
+	    at present, unfortunately.  The list of current obstacles
+	    includes:
+	    <list>
+	      <item>
+		<tt>/usr/doc</tt> (see <ref id="usrdoc">)
+		  is not allowed by FHS
+	      </item>
+	      <item>
+		<tt>/usr/local</tt> stub directories (described in the
+		following section) are not allowed by FHS
+	      </item>
+	    </list>
+	  </p>
+
+	</sect1>
 	    
 	    
 	<sect1>
 	  <heading>Site-specific programs</heading>
 	    
 	  <p>
-	    As mandated by the FHS no package should place any
-	    files in <tt>/usr/local</tt>, either by putting them in
-	    the file system archive to be unpacked by <prgn>dpkg</prgn>
-	    or by manipulating them in their maintainer scripts.</p>
+	    As mandated by the FHS, no package should place any
+	    files in <tt>/usr/local</tt>.  Do not include any files in
+	    the file system archive to be unpacked by <prgn>dpkg</prgn>,
+	    and do not manipulate files in the maintainer scripts.</p>
 	    
 	  <p>
 	    However, the package should create empty directories below


Reply to: