Debian-Project - Release Goals for Version 2.1

Make slink FHS-compliance

This has been proposed by Yann Dirson and elaborated by James R. Van Zandt.

The FHS.

1. Documentation

   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. /var/lib is deprecated 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. Exceptions from the FHS 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.")

   Alternative proposal by Raul Miller:

   1. Change the policy,
   2. Make some essential package for slink provide the symlink /usr/share -> ..
   3. Modify lintian to issue an error for use of /usr when /usr/share is appropriate, same for references to /usr/man, /usr/info, /usr/doc/.
   4. Update all packages and support programs.
   5. Eventually, when everything is converted, modify that essential package so that /usr/share is a proper directory, and the documenation directories are moved under /usr/share/.