(debian-policy.info)File System Structure

---

Next: Site-specific programs Up: File system hierarchy

---

Enter node , (file) or (file)node

9.1.1 File System Structure
---------------------------

The location of all files and directories must comply with the
Filesystem Hierarchy Standard (FHS), version 3.0, with the exceptions
noted below, and except where doing so would violate other terms of
Debian Policy.  The following exceptions to the FHS apply:

  1. The FHS requirement that architecture-independent
     application-specific static files be located in ‘/usr/share’ is
     relaxed to a suggestion.  In particular, a subdirectory of
     ‘/usr/lib’ may be used by a package (or a collection of packages)
     to hold a mixture of architecture-independent and
     architecture-dependent files.  However, when a directory is
     entirely composed of architecture-independent files, it should be
     located in ‘/usr/share’.

  2. The optional rules related to user specific configuration files for
     applications are stored in the user’s home directory are relaxed.
     It is recommended that such files start with the ‘‘.’’ character (a
     “dot file”), and if an application needs to create more than one
     dot file then the preferred placement is in a subdirectory with a
     name starting with a ‘.’ character, (a “dot directory”).  In this
     case it is recommended the configuration files not start with the
     ‘.’ character.

  3. Only the dynamic linker and libc are allowed to install files in
     ‘/lib64’.

  4. The requirement for object files, internal binaries, and libraries,
     including ‘libc.so.*’, to be located directly under ‘/lib{,32}’ and
     ‘/usr/lib{,32}’ is amended, permitting files to instead be
     installed to ‘/lib/triplet’ and ‘/usr/lib/triplet’, where ‘triplet’
     is the value returned by ‘dpkg-architecture -qDEB_HOST_MULTIARCH’
     for the architecture of the package.  Packages may `not' install
     files to any triplet path other than the one matching the
     architecture of that package; for instance, an ‘Architecture:
     amd64’ package containing 32-bit x86 libraries may not install
     these libraries to ‘/usr/lib/i386-linux-gnu’.  (1)

     No package for a 64 bit architecture may install files in
     ‘/usr/lib64/’ or in a subdirectory of it.

     The requirement for C and C++ headers files to be accessible
     through the search path ‘/usr/include/’ is amended, permitting
     files to be accessible through the search path
     ‘/usr/include/triplet’ where ‘triplet’ is as above.  (2)

     Applications may also use a single subdirectory under
     ‘/usr/lib/triplet’.

     The execution time linker/loader, ld*, must still be made available
     in the existing location under /lib or /lib64 since this is part of
     the ELF ABI for the architecture.

  5. The requirement that ‘/usr/local/share/man’ be “synonymous” with
     ‘/usr/local/man’ is relaxed to a recommendation

  6. The requirement that window managers with a single configuration
     file call it ‘system.*wmrc’ is removed, as is the restriction that
     the window manager subdirectory be named identically to the window
     manager name itself.

  7. The requirement that boot manager configuration files live in
     ‘/etc’, or at least are symlinked there, is relaxed to a
     recommendation.

  8. ‘/var/run’ is required to be a symbolic link to ‘/run’, and
     ‘/var/lock’ is required to be a symbolic link to ‘/run/lock’.

  9. The ‘/var/www’ directory is additionally allowed.

  10. The requirement for ‘/usr/local/share/color’ to exist if
     ‘/usr/share/color’ exists is relaxed to a recommendation.

  11. The requirement for ‘/usr/local/libqual’ to exist if ‘/libqual’ or
     ‘/usr/libqual’ exists (where ‘libqual’ is a variant of ‘lib’ such
     as ‘lib32’ or ‘lib64’) is removed.

  12. On GNU/Hurd systems, the following additional directories are
     allowed in the root filesystem: ‘/hurd’ and ‘/servers’.  (3)

  13. As an exception to the requirement for there to be no
     subdirectories in ‘/usr/bin’, the ‘mh’ mail-handling suite may
     create ‘/usr/bin/mh/’, as was allowed in FHS version 2.3.  Other
     subdirectories are not allowed.

The version of this document referred here can be found in the
‘debian-policy’ package or on FHS (Debian copy)(4) alongside this manual
(or, if you have the debian-policy installed, you can try FHS (local
copy)(5)).  The latest version, which may be a more recent version, may
be found on FHS (upstream)(6).  Specific questions about following the
standard may be asked on the ‘debian-devel’ mailing list, or referred to
the FHS mailing list (see the FHS web site(7) for more information).

   ---------- Footnotes ----------

   (1) This is necessary in order to reserve the directories for use in
cross-installation of library packages from other architectures, as part
of ‘multiarch’.

   (2) This is necessary for architecture-dependent headers file to
coexist in a ‘multiarch’ setup.

   (3) These directories are used to store translators and as a set of
standard names for mount points, respectively.

   (4) https://www.debian.org/doc/packaging-manuals/fhs/

   (5) file:///usr/share/doc/debian-policy/fhs/

   (6) http://refspecs.linuxfoundation.org/fhs.shtml

   (7) http://refspecs.linuxfoundation.org/fhs.shtml