"goals" for slink: FHS

["James R. Van Zandt" <jrv@vanzandt.mv.com>]

I think we have agreed to move toward FHS compliance, starting with
slink.  I have looked at the FHS (http://www.pathname.com/fhs/), and
have a few proposals:


			- 1 -

The first major change I see is that documentation has moved to
/usr/share.  To accommodate this, I suggest we take the following
steps:

   1. Change the policy to specify man pages in /usr/share/man, info
   pages in /usr/share/info, and miscellaneous docs in /usr/share/doc.
   (Who is maintaining the policy now?)
   
   2. Modify the man and info readers to look for files in
   /usr/share/{man,info} in addition to the current places.  Likewise
   info2www, man2html, dhelp, and dwww.
   
   3. Modify install-info (from the dpkg package) to work with files
   in /usr/share/info as well as /usr/info (that is, maintain a "dir"
   file in each directory).  Likewise, modify dhelp_parse to generate
   its index in /usr/share/doc/HTML.
   
   4. Modify debhelper and debmake to put man and info files in
   /usr/share/{man,info}, and miscellaneous docs into /usr/share/doc.
   
   5. Ask developers to start using the new locations, and update the
   manpages* packages.
   
   6. Modify lintian to issue a warning for documentation outside
   /usr/share.

   7. (much later) Change the lintian warning to an error.

I think the steps have to be done in pretty close to this order.  I
may have missed some steps, though.  In particular, I don't know how
HTML docs are handled.  

I am not proposing that we have to complete all these steps, let alone
convert all our packages, before releasing slink.  In fact, a mixed
system will be somewhat awkward.  Maybe we should get slink released
before we go to step 4.

			- 2 -

The other major change I see is that /var/lib is deprecated, in favor
of /var/state.  That means of course that all the dpkg state files get
moved, which I suspect will have endless ramifications.  The FHS does
allow for some leeway, though:

   5.11 ... /var/lib is deprecated, but it may be used in parallel
   with the required /var/state hierarchy, as a transitional measure
   for application-specific data.  Note, however, that this allowance
   will be removed in a future release of the standard.  Alternately,
   /var/lib may be made a symbolic link to /var/state.

Maybe we should use that symbolic link option for a while, at least.

			- 3 -

I believe we will take exception to these parts of the FHS, and I
think we should adopt some official statement to that effect:

   6.1.5  /usr/include : Header files included by C programs
   
   These symbolic links are required if a C or C++ compiler is installed.
   
       /usr/include/asm -> /usr/src/linux/include/asm-<arch>
       /usr/include/linux -> /usr/src/linux/include/linux
   
   
   6.1.6  /usr/src : Source code
   
   The only source code that should be placed in a specific location is
   the
   Linux kernel source code.  It is located in /usr/src/linux.
   
   If a C or C++ compiler is installed, but the complete Linux kernel
   source code is not installed, then the include files from the kernel
   source code shall be located in these directories:
   
       /usr/src/linux/include/asm-<arch>
   
   <arch> is the name of the system architecture.
   
   Note: /usr/src/linux may be a symbolic link to a kernel source code
   tree.

(Note that even a "partially compliant" distribution is required to
include "a list of all places at which it and the FHS document differ
in addition to a brief explanation of the reasoning for this
difference.")


Comments?  

(Incidently, I have included as explicit addressees the maintainers of
several packages I've mentioned.  I hope they don't mind.  However,
followups should probably be addressed only to debian-devel.)

                                    - Jim Van Zandt


--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org