Gecko [ fernandoquevedodop.com ]

Name	Size	Permission
_images	[ DIR ]	drwxr-xr-x
_sources	[ DIR ]	drwxr-xr-x
_static	[ DIR ]	drwxr-xr-x
ap-flowcharts.html	7.02 KB	-rw-r--r--
ap-license.html	4.8 KB	-rw-r--r--
ap-pkg-alternatives.html	6.79 KB	-rw-r--r--
ap-pkg-binarypkg.html	17.44 KB	-rw-r--r--
ap-pkg-conffiles.html	12.14 KB	-rw-r--r--
ap-pkg-controlfields.html	12.4 KB	-rw-r--r--
ap-pkg-diversions.html	11.4 KB	-rw-r--r--
ap-pkg-scope.html	7.81 KB	-rw-r--r--
ap-pkg-sourcepkg.html	33.32 KB	-rw-r--r--
ap-process.html	18.49 KB	-rw-r--r--
ch-archive.html	28.57 KB	-rw-r--r--
ch-binary.html	38.01 KB	-rw-r--r--
ch-controlfields.html	107.38 KB	-rw-r--r--
ch-customized-programs.html	53.09 KB	-rw-r--r--
ch-docs.html	33.97 KB	-rw-r--r--
ch-files.html	69.51 KB	-rw-r--r--
ch-maintainerscripts.html	40.34 KB	-rw-r--r--
ch-opersys.html	84.18 KB	-rw-r--r--
ch-relationships.html	67.18 KB	-rw-r--r--
ch-scope.html	18.54 KB	-rw-r--r--
ch-sharedlibs.html	88.6 KB	-rw-r--r--
ch-source.html	79.4 KB	-rw-r--r--
genindex.html	3.48 KB	-rw-r--r--
index.html	59.51 KB	-rw-r--r--
objects.inv	4.75 KB	-rw-r--r--
search.html	2.99 KB	-rw-r--r--
searchindex.js	58.77 KB	-rw-r--r--
upgrading-checklist.html	121.38 KB	-rw-r--r--

Code Editor : ch-files.html

<!DOCTYPE html>

<title>10. Files &#8212; Debian Policy Manual v4.6.0.1</title>
 <link rel="stylesheet" type="text/css" href="_static/pygments.css" />
 <link rel="stylesheet" type="text/css" href="_static/nature.css" />
 <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
 <script src="_static/jquery.js"></script>
 <script src="_static/underscore.js"></script>
 <script src="_static/doctools.js"></script>
 <link rel="index" title="Index" href="genindex.html" />
 <link rel="search" title="Search" href="search.html" />
 <link rel="next" title="11. Customized programs" href="ch-customized-programs.html" />
 <link rel="prev" title="9. The Operating System" href="ch-opersys.html" /> 
 </head><body>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="genindex.html" title="General Index"
 accesskey="I">index</a></li>
 <li class="right" >
 <a href="ch-customized-programs.html" title="11. Customized programs"
 accesskey="N">next</a> |</li>
 <li class="right" >
 <a href="ch-opersys.html" title="9. The Operating System"
 accesskey="P">previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">10. Files</a></li> 
 </ul>
 </div>

<div class="document">
 <div class="documentwrapper">
 <div class="bodywrapper">
 <div class="body" role="main">
 
 <section id="files">
<h1>10. Files<a class="headerlink" href="#files" title="Permalink to this headline">¶</a></h1>
<section id="binaries">
<h2>10.1. Binaries<a class="headerlink" href="#binaries" title="Permalink to this headline">¶</a></h2>
Two different packages must not install programs with different
functionality but with the same filenames. (The case of two programs
having the same functionality but different implementations is handled
via “alternatives” or the “Conflicts” mechanism. See
<a class="reference internal" href="ch-binary.html#s-maintscripts">Maintainer Scripts</a> and
<a class="reference internal" href="ch-relationships.html#s-conflicts">Conflicting binary packages - Conflicts</a> respectively.) If this case happens,
one of the programs must be renamed. The maintainers should report this
to the <code class="docutils literal notranslate">debian-devel</code> mailing list and try to find a consensus about
which program will have to be renamed. If a consensus cannot be reached,
both programs must be renamed.
To support merged-<code class="docutils literal notranslate">/usr</code> systems, packages must not install files in
both <code class="docutils literal notranslate">/path</code> and <code class="docutils literal notranslate">/usr/path</code>. For example, a package must not install
both <code class="docutils literal notranslate">/bin/example</code> and <code class="docutils literal notranslate">/usr/bin/example</code>.
If a file is moved between <code class="docutils literal notranslate">/path</code> and <code class="docutils literal notranslate">/usr/path</code> in revisions of a
Debian package, and a compatibility symlink at the old path is needed,
the symlink must be managed in a way that will not break when <code class="docutils literal notranslate">/path</code>
and <code class="docutils literal notranslate">/usr/path</code> are the same underlying directory due to symlinks or
other mechanisms.
Binary executables must not be statically linked with the GNU C library,
since this prevents the binary from benefiting from fixes and
improvements to the C library without being rebuilt and complicates
security updates. This requirement may be relaxed for binary executables
whose intended purpose is to diagnose and fix the system in situations
where the GNU C library may not be usable (such as system recovery
shells or utilities like ldconfig) or for binary executables where the
security benefits of static linking outweigh the drawbacks.
By default, when a package is being built, any binaries created should
include debugging information, as well as being compiled with
optimization. You should also turn on as many reasonable compilation
warnings as possible (see <a class="reference internal" href="ch-source.html#s-debianrules">Main building script: debian/rules</a>). For the C programming
language, this means the following compilation parameters should be
used:
<div class="highlight-default notranslate"><div class="highlight"><pre>CC = gcc
CFLAGS = -O2 -g -Wall # sane warning options vary between programs
LDFLAGS = # none
</pre></div>
</div>
By default all installed binaries should be stripped by calling
<div class="highlight-default notranslate"><div class="highlight"><pre>strip --strip-unneeded --remove-section=.comment --remove-section=.note binaries
</pre></div>
</div>
on the binaries after they have been copied into <code class="docutils literal notranslate">debian/tmp</code> but
before the tree is made into a package.
It is not recommended to strip binaries by passing the <code class="docutils literal notranslate">-s</code> flag to
<code class="docutils literal notranslate">install</code>, because this fails to remove .comment and .note sections,
and also prevents the automatic creation of dbgsym binary packages by
tools like <code class="docutils literal notranslate">dh_strip</code>.
Although binaries in the build tree should be compiled with debugging
information by default, it can often be difficult to debug programs if
they are also subjected to compiler optimization. For this reason, it is
recommended to support the standardized environment variable
<code class="docutils literal notranslate">DEB_BUILD_OPTIONS</code> (see <a class="reference internal" href="ch-source.html#s-debianrules-options">debian/rules and DEB_BUILD_OPTIONS</a>).
This variable can contain several flags to change how a package is
compiled and built.
It is up to the package maintainer to decide what compilation options
are best for the package. Certain binaries (such as
computationally-intensive programs) will function better with certain
flags (<code class="docutils literal notranslate">-O3</code>, for example); feel free to use them. Please use good
judgment here. Don’t use flags for the sake of it; only use them if
there is good reason to do so. Feel free to override the upstream
author’s ideas about which compilation options are best: they are often
inappropriate for our environment.
</section>
<section id="libraries">
<h2>10.2. Libraries<a class="headerlink" href="#libraries" title="Permalink to this headline">¶</a></h2>
If the package is architecture: any, then the shared library
compilation and linking flags must have <code class="docutils literal notranslate">-fPIC</code>, or the package shall
not build on some of the supported architectures. <a class="footnote-reference brackets" href="#id16" id="id1">1</a> Any exception
to this rule must be discussed on the mailing list
debian-devel&#64;lists.debian.org, and a rough consensus obtained. The
reasons for not compiling with <code class="docutils literal notranslate">-fPIC</code> flag must be recorded in the
file <code class="docutils literal notranslate">README.Debian</code>, and care must be taken to either restrict the
architecture or arrange for <code class="docutils literal notranslate">-fPIC</code> to be used on architectures where
it is required. <a class="footnote-reference brackets" href="#id17" id="id2">2</a>
As to the static libraries, the common case is not to have relocatable
code, since there is no benefit, unless in specific cases; therefore the
static version must not be compiled with the <code class="docutils literal notranslate">-fPIC</code> flag. Any
exception to this rule should be discussed on the mailing list
debian-devel&#64;lists.debian.org, and the reasons for compiling with the
<code class="docutils literal notranslate">-fPIC</code> flag must be recorded in the file <code class="docutils literal notranslate">README.Debian</code>. <a class="footnote-reference brackets" href="#id18" id="id3">3</a>
In other words, if both a shared and a static library is being built,
each source unit (<code class="docutils literal notranslate">*.c</code>, for example, for C files) will need to be
compiled twice, for the normal case.
Libraries should be built with threading support and to be thread-safe
if the library supports this.
Although not enforced by the build tools, shared libraries must be
linked against all libraries that they use symbols from in the same way
that binaries are. This ensures the correct functioning of the
<a class="reference internal" href="ch-sharedlibs.html#s-sharedlibs-symbols">symbols</a> and <a class="reference internal" href="ch-sharedlibs.html#s-sharedlibs-shlibdeps">shlibs</a> systems and guarantees that all
libraries can be safely opened with <code class="docutils literal notranslate">dlopen()</code>. Packagers may wish to
use the gcc option <code class="docutils literal notranslate">-Wl,-z,defs</code> when building a shared library. Since
this option enforces symbol resolution at build time, a missing library
reference will be caught early as a fatal build error.
All installed shared libraries should be stripped with
<div class="highlight-default notranslate"><div class="highlight"><pre>strip --strip-unneeded --remove-section=.comment --remove-section=.note your-lib
</pre></div>
</div>
(The option <code class="docutils literal notranslate">--strip-unneeded</code> makes <code class="docutils literal notranslate">strip</code> remove only the symbols
which aren’t needed for relocation processing.) Shared libraries can
function perfectly well when stripped, since the symbols for dynamic
linking are in a separate part of the ELF object file. <a class="footnote-reference brackets" href="#id19" id="id4">4</a>
Note that under some circumstances it may be useful to install a shared
library unstripped, for example when building a separate package to
support debugging. The debhelper <cite>dh_strip`</cite> tool can create such
packages automatically.
Shared object files (often <code class="docutils literal notranslate">.so</code> files) that are not public
libraries, that is, they are not meant to be linked to by third party
executables (binaries of other packages), should be installed in
subdirectories of the <code class="docutils literal notranslate">/usr/lib</code> or <code class="docutils literal notranslate">/usr/lib/triplet</code> directories
(see the FHS for a definition). Such files are exempt from the rules
that govern ordinary shared libraries, except that they must not be
installed executable and should be stripped. <a class="footnote-reference brackets" href="#id20" id="id5">5</a>
Packages that use <code class="docutils literal notranslate">libtool</code> to create and install their shared
libraries install a file containing additional metadata (ending in
<code class="docutils literal notranslate">.la</code>) alongside the library. For public libraries intended for use by
other packages, these files normally should not be included in the
Debian package, since the information they include is not necessary to
link with the shared library on Debian and can add unnecessary
additional dependencies to other programs or libraries. <a class="footnote-reference brackets" href="#id21" id="id6">6</a> If the
<code class="docutils literal notranslate">.la</code> file is required for that library (if, for instance, it’s loaded
via <code class="docutils literal notranslate">libltdl</code> in a way that requires that meta-information), the
<code class="docutils literal notranslate">dependency_libs</code> setting in the <code class="docutils literal notranslate">.la</code> file should normally be set
to the empty string. If the shared library development package has
historically included the <code class="docutils literal notranslate">.la</code>, it must be retained in the
development package (with <code class="docutils literal notranslate">dependency_libs</code> emptied) until all
libraries that depend on it have removed or emptied <code class="docutils literal notranslate">dependency_libs</code>
in their <code class="docutils literal notranslate">.la</code> files to prevent linking with those other libraries
using <code class="docutils literal notranslate">libtool</code> from failing.
If the <code class="docutils literal notranslate">.la</code> must be included, it should be included in the
development (<code class="docutils literal notranslate">-dev</code>) package, unless the library will be loaded by
<code class="docutils literal notranslate">libtool</code>’s <code class="docutils literal notranslate">libltdl</code> library. If it is intended for use with
<code class="docutils literal notranslate">libltdl</code>, the <code class="docutils literal notranslate">.la</code> files must go in the run-time library package.
These requirements for handling of <code class="docutils literal notranslate">.la</code> files do not apply to
loadable modules or libraries not installed in directories searched by
default by the dynamic linker. Packages installing loadable modules will
frequently need to install the <code class="docutils literal notranslate">.la</code> files alongside the modules so
that they can be loaded by <code class="docutils literal notranslate">libltdl</code>. <code class="docutils literal notranslate">dependency_libs</code> does not
need to be modified for libraries or modules that are not installed in
directories searched by the dynamic linker by default and not intended
for use by other packages.
You must make sure that you use only released versions of shared
libraries to build your packages; otherwise other users will not be able
to run your binaries properly. Producing source packages that depend on
unreleased compilers is also usually a bad idea.
</section>
<section id="shared-libraries">
<h2>10.3. Shared libraries<a class="headerlink" href="#shared-libraries" title="Permalink to this headline">¶</a></h2>
This section has moved to <a class="reference internal" href="ch-sharedlibs.html">Shared libraries</a>.
</section>
<section id="scripts">
<h2>10.4. Scripts<a class="headerlink" href="#scripts" title="Permalink to this headline">¶</a></h2>
All command scripts, including the package maintainer scripts inside the
package and used by <code class="docutils literal notranslate">dpkg</code>, should have a <code class="docutils literal notranslate">#!</code> line naming the shell
to be used to interpret them.
In the case of Perl scripts this should be <code class="docutils literal notranslate">#!/usr/bin/perl</code>.
When scripts are installed into a directory in the system PATH, the
script name should not include an extension such as <code class="docutils literal notranslate">.sh</code> or <code class="docutils literal notranslate">.pl</code>
that denotes the scripting language currently used to implement it.
Shell scripts (<code class="docutils literal notranslate">sh</code> and <code class="docutils literal notranslate">bash</code>) other than <code class="docutils literal notranslate">init.d</code> scripts should
almost certainly start with <code class="docutils literal notranslate">set -e</code> so that errors are detected.
<code class="docutils literal notranslate">init.d</code> scripts are something of a special case, due to how
frequently they need to call commands that are allowed to fail, and it
may instead be easier to check the exit status of commands directly. See
<a class="reference internal" href="ch-opersys.html#s-writing-init">Writing the scripts</a> for more information about writing
<code class="docutils literal notranslate">init.d</code> scripts.
Every script should use <code class="docutils literal notranslate">set -e</code> or check the exit status of every
command.
Scripts may assume that <code class="docutils literal notranslate">/bin/sh</code> implements the POSIX.1-2017 Shell Command
Language <a class="footnote-reference brackets" href="#id22" id="id7">7</a> plus the following additional features not mandated by
POSIX.1-2017.. <a class="footnote-reference brackets" href="#id23" id="id8">8</a>
<ul>
<li><code class="docutils literal notranslate">echo -n</code>, if implemented as a shell built-in, must not generate a
newline.</li>
<li><code class="docutils literal notranslate">test</code>, if implemented as a shell built-in, must support <code class="docutils literal notranslate">-a</code> and
<code class="docutils literal notranslate">-o</code> as binary logical operators.</li>
<li><code class="docutils literal notranslate">local</code> to create a scoped variable must be supported, including
listing multiple variables in a single local command and assigning a
value to a variable at the same time as localizing it. <code class="docutils literal notranslate">local</code> may
or may not preserve the variable value from an outer scope if no
assignment is present. Uses such as:
<div class="highlight-default notranslate"><div class="highlight"><pre>fname () {
 local a b c=delta d
 # ... use a, b, c, d ...
}
</pre></div>
</div>
must be supported and must set the value of <code class="docutils literal notranslate">c</code> to <code class="docutils literal notranslate">delta</code>.
</li>
<li>The XSI extension to <code class="docutils literal notranslate">kill</code> allowing <code class="docutils literal notranslate">kill -signal</code>, where signal
is either the name of a signal or one of the numeric signals listed
in the XSI extension (0, 1, 2, 3, 6, 9, 14, and 15), must be
supported if <code class="docutils literal notranslate">kill</code> is implemented as a shell built-in.</li>
<li>The XSI extension to <code class="docutils literal notranslate">trap</code> allowing numeric signals must be
supported. In addition to the signal numbers listed in the extension,
which are the same as for <code class="docutils literal notranslate">kill</code> above, 13 (SIGPIPE) must be
allowed.</li>
</ul>
If a shell script requires non-POSIX.1-2017 features from the shell interpreter
other than those listed above, the appropriate shell must be specified
in the first line of the script (e.g., <code class="docutils literal notranslate">#!/bin/bash</code>) and the package
must depend on the package providing the shell (unless the shell package
is marked “Essential”, as in the case of <code class="docutils literal notranslate">bash</code>).
You may wish to restrict your script to POSIX.1-2017 features plus the above
set when possible so that it may use <code class="docutils literal notranslate">/bin/sh</code> as its interpreter.
Checking your script with <code class="docutils literal notranslate">checkbashisms</code> from the devscripts package
or running your script with an alternate shell such as <code class="docutils literal notranslate">posh</code> may help
uncover violations of the above requirements. If in doubt whether a
script complies with these requirements, use <code class="docutils literal notranslate">/bin/bash</code>.
Perl scripts should check for errors when making any system calls,
including <code class="docutils literal notranslate">open</code>, <code class="docutils literal notranslate">print</code>, <code class="docutils literal notranslate">close</code>, <code class="docutils literal notranslate">rename</code> and <code class="docutils literal notranslate">system</code>.
<code class="docutils literal notranslate">csh</code> and <code class="docutils literal notranslate">tcsh</code> should be avoided as scripting languages. See Csh
Programming Considered Harmful, one of the <code class="docutils literal notranslate">comp.unix.*</code> FAQs, which
can be found at <a class="reference external" href="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/">http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/</a>. If
an upstream package comes with <code class="docutils literal notranslate">csh</code> scripts then you must make sure
that they start with <code class="docutils literal notranslate">#!/bin/csh</code> and make your package depend on the
<code class="docutils literal notranslate">c-shell</code> virtual package.
Any scripts which create files in world-writeable directories (e.g., in
<code class="docutils literal notranslate">/tmp</code>) must use a mechanism which will fail atomically if a file with
the same name already exists.
The Debian base system provides the <code class="docutils literal notranslate">tempfile</code> and <code class="docutils literal notranslate">mktemp</code>
utilities for use by scripts for this purpose.
</section>
<section id="symbolic-links">
<h2>10.5. Symbolic links<a class="headerlink" href="#symbolic-links" title="Permalink to this headline">¶</a></h2>
In general, symbolic links within a top-level directory should be
relative, and symbolic links pointing from one top-level directory to or
into another should be absolute. (A top-level directory is a
sub-directory of the root directory <code class="docutils literal notranslate">/</code>.) For example, a symbolic link
from <code class="docutils literal notranslate">/usr/lib/foo</code> to <code class="docutils literal notranslate">/usr/share/bar</code> should be relative
(<code class="docutils literal notranslate">../share/bar</code>), but a symbolic link from <code class="docutils literal notranslate">/var/run</code> to <code class="docutils literal notranslate">/run</code>
should be absolute. <a class="footnote-reference brackets" href="#id24" id="id9">9</a> Symbolic links must not traverse above the
root directory.
In addition, symbolic links should be specified as short as possible,
i.e., link targets like <code class="docutils literal notranslate">foo/../bar</code> are deprecated.
Note that when creating a relative link using <code class="docutils literal notranslate">ln</code> it is not necessary
for the target of the link to exist relative to the working directory
you’re running <code class="docutils literal notranslate">ln</code> from, nor is it necessary to change directory to
the directory where the link is to be made. Simply include the string
that should appear as the target of the link (this will be a pathname
relative to the directory in which the link resides) as the first
argument to <code class="docutils literal notranslate">ln</code>.
For example, in your <code class="docutils literal notranslate">Makefile</code> or <code class="docutils literal notranslate">debian/rules</code>, you can do things
like:
<div class="highlight-default notranslate"><div class="highlight"><pre>ln -fs gcc $(prefix)/bin/cc
ln -fs gcc debian/tmp/usr/bin/cc
ln -fs ../sbin/sendmail $(prefix)/bin/runq
ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
</pre></div>
</div>
A symbolic link pointing to a compressed file (in the sense that it is
meant to be uncompressed with <code class="docutils literal notranslate">unzip</code> or <code class="docutils literal notranslate">zless</code> etc.) should always
have the same file extension as the referenced file. (For example, if a
file <code class="docutils literal notranslate">foo.gz</code> is referenced by a symbolic link, the filename of the
link has to end with “<code class="docutils literal notranslate">.gz</code>” too, as in <code class="docutils literal notranslate">bar.gz</code>.)
</section>
<section id="device-files">
<h2>10.6. Device files<a class="headerlink" href="#device-files" title="Permalink to this headline">¶</a></h2>
Packages must not include device files or named pipes in the package
file tree.
Debian packages should assume that device files in <code class="docutils literal notranslate">/dev</code> are
dynamically managed by the kernel or some other system facility and do
not have to be explicitly created or managed by the package. Debian
packages other than those whose purpose is to manage the <code class="docutils literal notranslate">/dev</code> device
file tree must not attempt to create or remove device files in <code class="docutils literal notranslate">/dev</code>
when a dynamic device management facility is in use.
If named pipes or device files outside of <code class="docutils literal notranslate">/dev</code> are required by a
package, they should normally be created when necessary by the programs
in the package, by init scripts or systemd unit files, or by similar
on-demand mechanisms. If such files need to be created during package
installation, they must be created in the <code class="docutils literal notranslate">postinst</code> maintainer script
<a class="footnote-reference brackets" href="#id25" id="id10">10</a> and removed in either the <code class="docutils literal notranslate">prerm</code> or the <code class="docutils literal notranslate">postrm</code> maintainer
script.
</section>
<section id="configuration-files">
<h2>10.7. Configuration files<a class="headerlink" href="#configuration-files" title="Permalink to this headline">¶</a></h2>
<section id="definitions">
<h3>10.7.1. Definitions<a class="headerlink" href="#definitions" title="Permalink to this headline">¶</a></h3>
<dl class="simple">
<dt>configuration file</dt><dd>A file that affects the operation of a program, or provides site- or
host-specific information, or otherwise customizes the behavior of a
program. Typically, configuration files are intended to be modified
by the system administrator (if needed or desired) to conform to
local policy or to provide more useful site-specific behavior.
</dd>
<dt><code class="docutils literal notranslate">conffile</code></dt><dd>A file listed in a package’s <code class="docutils literal notranslate">conffiles</code> file, and is treated
specially by <code class="docutils literal notranslate">dpkg</code> (see <a class="reference internal" href="ch-maintainerscripts.html#s-configdetails">Details of configuration</a>).
</dd>
</dl>
The distinction between these two is important; they are not
interchangeable concepts. Almost all <code class="docutils literal notranslate">conffile</code>s are configuration
files, but many configuration files are not <code class="docutils literal notranslate">conffiles</code>.
As noted elsewhere, <code class="docutils literal notranslate">/etc/init.d</code> scripts, <code class="docutils literal notranslate">/etc/default</code> files,
scripts installed in <code class="docutils literal notranslate">/etc/cron.{hourly,daily,weekly,monthly}</code>, and
cron configuration installed in <code class="docutils literal notranslate">/etc/cron.d</code> must be treated as
configuration files. In general, any script that embeds configuration
information is de-facto a configuration file and should be treated as
such.
</section>
<section id="location">
<h3>10.7.2. Location<a class="headerlink" href="#location" title="Permalink to this headline">¶</a></h3>
Any configuration files created or used by your package must reside in
<code class="docutils literal notranslate">/etc</code>. If there are several, consider creating a subdirectory of
<code class="docutils literal notranslate">/etc</code> named after your package.
If your package creates or uses configuration files outside of <code class="docutils literal notranslate">/etc</code>,
and it is not feasible to modify the package to use <code class="docutils literal notranslate">/etc</code> directly,
put the files in <code class="docutils literal notranslate">/etc</code> and create symbolic links to those files from
the location that the package requires.
</section>
<section id="behavior">
<h3>10.7.3. Behavior<a class="headerlink" href="#behavior" title="Permalink to this headline">¶</a></h3>
Configuration file handling must conform to the following behavior:
<ul class="simple">
<li>local changes must be preserved during a package upgrade, and</li>
<li>configuration files must be preserved when the package is removed,
and only deleted when the package is purged.</li>
</ul>
Obsolete configuration files without local changes should be removed by
the package during upgrade. <a class="footnote-reference brackets" href="#id26" id="id11">11</a>
The easy way to achieve this behavior is to make the configuration file
a <code class="docutils literal notranslate">conffile</code>. This is appropriate only if it is possible to distribute
a default version that will work for most installations, although some
system administrators may choose to modify it. This implies that the
default version will be part of the package distribution, and must not
be modified by the maintainer scripts during installation (or at any
other time).
In order to ensure that local changes are preserved correctly, packages
must not contain or make hard links to conffiles. <a class="footnote-reference brackets" href="#id27" id="id12">12</a>
The other way to do it is via the maintainer scripts. In this case, the
configuration file must not be listed as a <code class="docutils literal notranslate">conffile</code> and must not be
part of the package distribution. If the existence of a file is required
for the package to be sensibly configured it is the responsibility of
the package maintainer to provide maintainer scripts which correctly
create, update and maintain the file and remove it on purge. (See
<a class="reference internal" href="ch-maintainerscripts.html">Package maintainer scripts and installation procedure</a>
for more information.) These scripts must be idempotent (i.e., must work
correctly if <code class="docutils literal notranslate">dpkg</code> needs to re-run them due to errors during
installation or removal), must cope with all the variety of ways
<code class="docutils literal notranslate">dpkg</code> can call maintainer scripts, must not overwrite or otherwise
mangle the user’s configuration without asking, must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens.
The scripts are not required to configure every possible option for the
package, but only those necessary to get the package running on a given
system. Ideally the sysadmin should not have to do any configuration
other than that done (semi-)automatically by the <code class="docutils literal notranslate">postinst</code> script.
A common practice is to create a script called <code class="docutils literal notranslate">package-configure</code> and
have the package’s <code class="docutils literal notranslate">postinst</code> call it if and only if the configuration
file does not already exist. In certain cases it is useful for there to
be an example or template file which the maintainer scripts use. Such
files should be in <code class="docutils literal notranslate">/usr/share/package</code> or <code class="docutils literal notranslate">/usr/lib/package</code>
(depending on whether they are architecture-independent or not). There
should be symbolic links to them from
<code class="docutils literal notranslate">/usr/share/doc/package/examples</code> if they are examples, and should be
perfectly ordinary <code class="docutils literal notranslate">dpkg</code>-handled files (not configuration files).
These two styles of configuration file handling must not be mixed, for
that way lies madness: <code class="docutils literal notranslate">dpkg</code> will ask about overwriting the file
every time the package is upgraded.
</section>
<section id="sharing-configuration-files">
<h3>10.7.4. Sharing configuration files<a class="headerlink" href="#sharing-configuration-files" title="Permalink to this headline">¶</a></h3>
If two or more packages use the same configuration file and it is
reasonable for both to be installed at the same time, one of these
packages must be defined as owner of the configuration file, i.e., it
will be the package which handles that file as a configuration file.
Other packages that use the configuration file must depend on the owning
package if they require the configuration file to operate. If the other
package will use the configuration file if present, but is capable of
operating without it, no dependency need be declared.
If it is desirable for two or more related packages to share a
configuration file and for all of the related packages to be able to
modify that configuration file, then the following should be done:
<ol class="arabic simple">
<li>One of the related packages (the “owning” package) will manage the
configuration file with maintainer scripts as described in the
previous section.</li>
<li>The owning package should also provide a program that the other
packages may use to modify the configuration file.</li>
<li>The related packages must use the provided program to make any
desired modifications to the configuration file. They should either
depend on the core package to guarantee that the configuration
modifier program is available or accept gracefully that they cannot
modify the configuration file if it is not. (This is in addition to
the fact that the configuration file may not even be present in the
latter scenario.)</li>
</ol>
Sometimes it’s appropriate to create a new package which provides the
basic infrastructure for the other packages and which manages the shared
configuration files. (The <code class="docutils literal notranslate">sgml-base</code> package is a good example.)
If the configuration file cannot be shared as described above, the
packages must be marked as conflicting with each other. Two packages
that specify the same file as a <code class="docutils literal notranslate">conffile</code> must conflict. This is an
instance of the general rule about not sharing files. Neither
alternatives nor diversions are likely to be appropriate in this case;
in particular, <code class="docutils literal notranslate">dpkg</code> does not handle diverted <code class="docutils literal notranslate">conffile</code>s well.
When two packages both declare the same <code class="docutils literal notranslate">conffile</code>, they may see
left-over configuration files from each other even though they conflict
with each other. If a user removes (without purging) one of the packages
and installs the other, the new package will take over the <code class="docutils literal notranslate">conffile</code>
from the old package. If the file was modified by the user, it will be
treated the same as any other locally modified <code class="docutils literal notranslate">conffile</code> during an
upgrade.
The maintainer scripts must not alter a <code class="docutils literal notranslate">conffile</code> of any package,
including the one the scripts belong to.
</section>
<section id="user-configuration-files-dotfiles">
<h3>10.7.5. User configuration files (“dotfiles”)<a class="headerlink" href="#user-configuration-files-dotfiles" title="Permalink to this headline">¶</a></h3>
The files in <code class="docutils literal notranslate">/etc/skel</code> will automatically be copied into new user
accounts by <code class="docutils literal notranslate">adduser</code>. No other program should reference the files in
<code class="docutils literal notranslate">/etc/skel</code>.
Therefore, if a program needs a dotfile to exist in advance in <code class="docutils literal notranslate">$HOME</code>
to work sensibly, that dotfile should be installed in <code class="docutils literal notranslate">/etc/skel</code> and
treated as a configuration file.
However, programs that require dotfiles in order to operate sensibly are
a bad thing, unless they do create the dotfiles themselves
automatically.
Furthermore, programs should be configured by the Debian default
installation to behave as closely to the upstream default behavior as
possible.
Therefore, if a program in a Debian package needs to be configured in
some way in order to operate sensibly, that should be done using a
site-wide configuration file placed in <code class="docutils literal notranslate">/etc</code>. Only if the program
doesn’t support a site-wide default configuration and the package
maintainer doesn’t have time to add it may a default per-user file be
placed in <code class="docutils literal notranslate">/etc/skel</code>.
<code class="docutils literal notranslate">/etc/skel</code> should be as empty as we can make it. This is particularly
true because there is no easy (or necessarily desirable) mechanism for
ensuring that the appropriate dotfiles are copied into the accounts of
existing users when a package is installed.
</section>
</section>
<section id="log-files">
<h2>10.8. Log files<a class="headerlink" href="#log-files" title="Permalink to this headline">¶</a></h2>
Log files should usually be named <code class="docutils literal notranslate">/var/log/package.log</code>. If you have
many log files, or need a separate directory for permission reasons
(<code class="docutils literal notranslate">/var/log</code> is writable only by <code class="docutils literal notranslate">root</code>), you should usually create a
directory named <code class="docutils literal notranslate">/var/log/package</code> and place your log files there.
Log files must be rotated occasionally so that they don’t grow
indefinitely. The best way to do this is to install a log rotation
configuration file in the directory <code class="docutils literal notranslate">/etc/logrotate.d</code>, normally named
<code class="docutils literal notranslate">/etc/logrotate.d/package</code>, and use the facilities provided by
<code class="docutils literal notranslate">logrotate</code>. <a class="footnote-reference brackets" href="#id28" id="id13">13</a> Here is a good example for a logrotate config file
(for more information see logrotate(8)):
<div class="highlight-default notranslate"><div class="highlight"><pre>/var/log/foo/*.log {
 rotate 12
 weekly
 compress
 missingok
 postrotate
 start-stop-daemon -K -p /var/run/foo.pid -s HUP -x /usr/sbin/foo -q
 endscript
}
</pre></div>
</div>
This rotates all files under <code class="docutils literal notranslate">/var/log/foo</code>, saves 12 compressed
generations, and tells the daemon to reopen its log files after the log
rotation. It skips this log rotation (via <code class="docutils literal notranslate">missingok</code>) if no such log
file is present, which avoids errors if the package is removed but not
purged.
Log files should be removed when the package is purged (but not when it
is only removed). This should be done by the <code class="docutils literal notranslate">postrm</code> script when it
is called with the argument <code class="docutils literal notranslate">purge</code> (see
<a class="reference internal" href="ch-maintainerscripts.html#s-removedetails">Details of removal and/or configuration purging</a>).
</section>
<section id="permissions-and-owners">
<h2>10.9. Permissions and owners<a class="headerlink" href="#permissions-and-owners" title="Permalink to this headline">¶</a></h2>
The rules in this section are guidelines for general use. If necessary
you may deviate from the details below. However, if you do so you must
make sure that what is done is secure and you should try to be as
consistent as possible with the rest of the system. You are also
encouraged to discuss it on <code class="docutils literal notranslate">debian-devel</code> first.
Files should be owned by <code class="docutils literal notranslate">root:root</code>, and made writable only by the
owner and universally readable (and executable, if appropriate), that is
mode 644 or 755.
Directories should be mode 755 or (for group-writability) mode 2775. The
ownership of the directory should be consistent with its mode: if a
directory is mode 2775, it should be owned by the group that needs write
access to it. <a class="footnote-reference brackets" href="#id29" id="id14">14</a>
Control information files should be owned by <code class="docutils literal notranslate">root:root</code> and either
mode 644 (for most files) or mode 755 (for executables such as
<a class="reference internal" href="ch-binary.html#s-maintscripts">maintainer scripts</a>).
Setuid and setgid executables should be mode 4755 or 2755 respectively,
and owned by the appropriate user or group. They should not be made
unreadable (modes like 4711 or 2711 or even 4111); doing so achieves no
extra security, because anyone can find the binary in the freely
available Debian package; it is merely inconvenient. For the same reason
you should not restrict read or execute permissions on non-set-id
executables.
Some setuid programs need to be restricted to particular sets of users,
using file permissions. In this case they should be owned by the uid to
which they are set-id, and by the group which should be allowed to
execute them. They should have mode 4754; again there is no point in
making them unreadable to those users who must not be allowed to execute
them.
It is possible to arrange that the system administrator can reconfigure
the package to correspond to their local security policy by changing the
permissions on a binary: they can do this by using
<code class="docutils literal notranslate">dpkg-statoverride</code>, as described below. <a class="footnote-reference brackets" href="#id30" id="id15">15</a> Another method you
should consider is to create a group for people allowed to use the
program(s) and make any setuid executables executable only by that
group.
If you need to create a new user or group for your package there are two
possibilities. Firstly, you may need to make some files in the binary
package be owned by this user or group, or you may need to compile the
user or group id (rather than just the name) into the binary (though
this latter should be avoided if possible, as in this case you need a
statically allocated id).
If you need a statically allocated id, you must ask for a user or group
id from the <code class="docutils literal notranslate">base-passwd</code> maintainer, and must not release the package
until you have been allocated one. Once you have been allocated one you
must either make the package depend on a version of the <code class="docutils literal notranslate">base-passwd</code>
package with the id present in <code class="docutils literal notranslate">/etc/passwd</code> or <code class="docutils literal notranslate">/etc/group</code>, or
arrange for your package to create the user or group itself with the
correct id (using <code class="docutils literal notranslate">adduser</code>) in its <code class="docutils literal notranslate">preinst</code> or <code class="docutils literal notranslate">postinst</code>.
(Doing it in the <code class="docutils literal notranslate">postinst</code> is to be preferred if it is possible,
otherwise a pre-dependency will be needed on the <code class="docutils literal notranslate">adduser</code> package.)
On the other hand, the program might be able to determine the uid or gid
from the user or group name at runtime, so that a dynamically allocated
id can be used. In this case you should choose an appropriate user or
group name, discussing this on <code class="docutils literal notranslate">debian-devel</code> and checking that it is
unique. When this has been checked you must arrange for your package to
create the user or group if necessary using <code class="docutils literal notranslate">adduser</code> in the
<code class="docutils literal notranslate">preinst</code> or <code class="docutils literal notranslate">postinst</code> script (again, the latter is to be preferred
if it is possible).
Note that changing the numeric value of an id associated with a name is
very difficult, and involves searching the file system for all
appropriate files. You need to think carefully whether a static or
dynamic id is required, since changing your mind later will cause
problems.
<section id="the-use-of-dpkg-statoverride">
<h3>10.9.1. The use of <code class="docutils literal notranslate">dpkg-statoverride</code><a class="headerlink" href="#the-use-of-dpkg-statoverride" title="Permalink to this headline">¶</a></h3>
This section is not intended as policy, but as a description of the use
of <code class="docutils literal notranslate">dpkg-statoverride</code>.
If a system administrator wishes to have a file (or directory or other
such thing) installed with owner and permissions different from those in
the distributed Debian package, they can use the <code class="docutils literal notranslate">dpkg-statoverride</code>
program to instruct <code class="docutils literal notranslate">dpkg</code> to use the different settings every time
the file is installed. Thus the package maintainer should distribute the
files with their normal permissions, and leave it for the system
administrator to make any desired changes. For example, a daemon which
is normally required to be setuid root, but in certain situations could
be used without being setuid, should be installed setuid in the
<code class="docutils literal notranslate">.deb</code>. Then the local system administrator can change this if they
wish. If there are two standard ways of doing it, the package maintainer
can use <code class="docutils literal notranslate">debconf</code> to find out the preference, and call
<code class="docutils literal notranslate">dpkg-statoverride</code> in the maintainer script if necessary to
accommodate the system administrator’s choice. Care must be taken during
upgrades to not override an existing setting.
Given the above, <code class="docutils literal notranslate">dpkg-statoverride</code> is essentially a tool for system
administrators and would not normally be needed in the maintainer
scripts. There is one type of situation, though, where calls to
<code class="docutils literal notranslate">dpkg-statoverride</code> would be needed in the maintainer scripts, and
that involves packages which use dynamically allocated user or group
ids. In such a situation, something like the following idiom can be very
helpful in the package’s <code class="docutils literal notranslate">postinst</code>, where <code class="docutils literal notranslate">sysuser</code> is a
dynamically allocated id:
<div class="highlight-default notranslate"><div class="highlight"><pre>for i in /usr/bin/foo /usr/sbin/bar; do
 # only do something when no setting exists
 if ! dpkg-statoverride --list $i &gt;/dev/null 2&gt;&amp;1; then
 #include: debconf processing, question about foo and bar
 if [ &quot;$RET&quot; = &quot;true&quot; ] ; then
 dpkg-statoverride --update --add sysuser root 4755 $i
 fi
 fi
done
</pre></div>
</div>
The corresponding code to remove the override when the package is purged
would be:
<div class="highlight-default notranslate"><div class="highlight"><pre>for i in /usr/bin/foo /usr/sbin/bar; do
 if dpkg-statoverride --list $i &gt;/dev/null 2&gt;&amp;1; then
 dpkg-statoverride --remove $i
 fi
done
</pre></div>
</div>
</section>
</section>
<section id="file-names">
<h2>10.10. File names<a class="headerlink" href="#file-names" title="Permalink to this headline">¶</a></h2>
The name of the files installed by binary packages in the system PATH
(namely <code class="docutils literal notranslate">/bin</code>, <code class="docutils literal notranslate">/sbin</code>, <code class="docutils literal notranslate">/usr/bin</code>, <code class="docutils literal notranslate">/usr/sbin</code> and
<code class="docutils literal notranslate">/usr/games</code>) must be encoded in ASCII.
The name of the files and directories installed by binary packages
outside the system PATH must be encoded in UTF-8 and should be
restricted to ASCII when it is possible to do so.
<dl class="footnote brackets">
<dt class="label" id="id16"><a class="fn-backref" href="#id1">1</a></dt>
<dd>If you are using GCC, <code class="docutils literal notranslate">-fPIC</code> produces code with relocatable
position independent code, which is required for most architectures
to create a shared library, with i386 and perhaps some others where
non position independent code is permitted in a shared library.
Position independent code may have a performance penalty, especially
on <code class="docutils literal notranslate">i386</code>. However, in most cases the speed penalty must be
measured against the memory wasted on the few architectures where non
position independent code is even possible.
</dd>
<dt class="label" id="id17"><a class="fn-backref" href="#id2">2</a></dt>
<dd>Some of the reasons why this might be required is if the library
contains hand crafted assembly code that is not relocatable, the
speed penalty is excessive for compute intensive libs, and similar
reasons.
</dd>
<dt class="label" id="id18"><a class="fn-backref" href="#id3">3</a></dt>
<dd>Some of the reasons for linking static libraries with the <code class="docutils literal notranslate">-fPIC</code>
flag are if, for example, one needs a Perl API for a library that is
under rapid development, and has an unstable API, so shared libraries
are pointless at this phase of the library’s development. In that
case, since Perl needs a library with relocatable code, it may make
sense to create a static library with relocatable code. Another
reason cited is if you are distilling various libraries into a common
shared library, like <code class="docutils literal notranslate">mklibs</code> does in the Debian installer project.
</dd>
<dt class="label" id="id19"><a class="fn-backref" href="#id4">4</a></dt>
<dd>You might want to replace <code class="docutils literal notranslate">--strip-unneeded</code> with
<code class="docutils literal notranslate">--strip-debug</code> for static libraries, as dh_strip does. When
stripping static libraries, you should also pass
<code class="docutils literal notranslate">--enable-deterministic-archives</code> to ensure that your package
build is reproducible.
</dd>
<dt class="label" id="id20"><a class="fn-backref" href="#id5">5</a></dt>
<dd>A common example are the so-called “plug-ins”, internal shared objects
that are dynamically loaded by programs using dlopen(3).
</dd>
<dt class="label" id="id21"><a class="fn-backref" href="#id6">6</a></dt>
<dd>These files store, among other things, all libraries on which that
shared library depends. Unfortunately, if the <code class="docutils literal notranslate">.la</code> file is present
and contains that dependency information, using <code class="docutils literal notranslate">libtool</code> when
linking against that library will cause the resulting program or
library to be linked against those dependencies as well, even if this
is unnecessary. This can create unneeded dependencies on shared
library packages that would otherwise be hidden behind the library
ABI, and can make library transitions to new SONAMEs unnecessarily
complicated and difficult to manage.
</dd>
<dt class="label" id="id22"><a class="fn-backref" href="#id7">7</a></dt>
<dd>The Open Group Base Specifications Issue 7, 2018 Edition, which is
also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
available on the World Wide Web from <a class="reference external" href="http://pubs.opengroup.org/onlinepubs/9699919799/download/">The Open Group</a>.
</dd>
<dt class="label" id="id23"><a class="fn-backref" href="#id8">8</a></dt>
<dd>These features are in widespread use in the Linux community and are
implemented in all of bash, dash, and ksh, the most common shells
users may wish to use as <code class="docutils literal notranslate">/bin/sh</code>.
</dd>
<dt class="label" id="id24"><a class="fn-backref" href="#id9">9</a></dt>
<dd>This is necessary to allow top-level directories to be symlinks. If
linking <code class="docutils literal notranslate">/var/run</code> to <code class="docutils literal notranslate">/run</code> were done with the relative symbolic
link <code class="docutils literal notranslate">../run</code>, but <code class="docutils literal notranslate">/var</code> were a symbolic link to <code class="docutils literal notranslate">/srv/disk1</code>,
the symbolic link would point to <code class="docutils literal notranslate">/srv/run</code> rather than the
intended target.
</dd>
<dt class="label" id="id25"><a class="fn-backref" href="#id10">10</a></dt>
<dd>It’s better to use <code class="docutils literal notranslate">mkfifo</code> rather than <code class="docutils literal notranslate">mknod</code> to create named
pipes to avoid false positives from automated checks for packages
incorrectly creating device files.
</dd>
<dt class="label" id="id26"><a class="fn-backref" href="#id11">11</a></dt>
<dd>The <code class="docutils literal notranslate">dpkg-maintscript-helper</code> tool, available from the dpkg
package, can help for this task.
</dd>
<dt class="label" id="id27"><a class="fn-backref" href="#id12">12</a></dt>
<dd>Rationale: There are two problems with hard links. The first is that
some editors break the link while editing one of the files, so that
the two files may unwittingly become unlinked and different. The
second is that <code class="docutils literal notranslate">dpkg</code> might break the hard link while upgrading
<code class="docutils literal notranslate">conffile</code>s.
</dd>
<dt class="label" id="id28"><a class="fn-backref" href="#id13">13</a></dt>
<dd>The traditional approach to log files has been to set up ad hoc log
rotation schemes using simple shell scripts and cron. While this
approach is highly customizable, it requires quite a lot of sysadmin
work. Even though the original Debian system helped a little by
automatically installing a system which can be used as a template,
this was deemed not enough.
The use of <code class="docutils literal notranslate">logrotate</code>, a program developed by Red Hat, is better,
as it centralizes log management. It has both a configuration file
(<code class="docutils literal notranslate">/etc/logrotate.conf</code>) and a directory where packages can drop
their individual log rotation configurations (<code class="docutils literal notranslate">/etc/logrotate.d</code>).
</dd>
<dt class="label" id="id29"><a class="fn-backref" href="#id14">14</a></dt>
<dd>When a package is upgraded, and the owner or permissions of a file
included in the package has changed, dpkg arranges for the ownership
and permissions to be correctly set upon installation. However, this
does not extend to directories; the permissions and ownership of
directories already on the system does not change on install or
upgrade of packages. This makes sense, since otherwise common
directories like <code class="docutils literal notranslate">/usr</code> would always be in flux. To correctly
change permissions of a directory the package owns, explicit action
is required, usually in the <code class="docutils literal notranslate">postinst</code> script. Care must be taken
to handle downgrades as well, in that case.
</dd>
<dt class="label" id="id30"><a class="fn-backref" href="#id15">15</a></dt>
<dd>Ordinary files installed by <code class="docutils literal notranslate">dpkg</code> (as opposed to <code class="docutils literal notranslate">conffile</code>s
and other similar objects) normally have their permissions reset to
the distributed permissions when the package is reinstalled. However,
the use of <code class="docutils literal notranslate">dpkg-statoverride</code> overrides this default behavior.
</dd>
</dl>
</section>
</section>

<div class="clearer"></div>
 </div>
 </div>
 </div>
 <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
 <div class="sphinxsidebarwrapper">
 <h3><a href="index.html">Table of Contents</a></h3>
 <ul>
<li><a class="reference internal" href="#">10. Files</a><ul>
<li><a class="reference internal" href="#binaries">10.1. Binaries</a></li>
<li><a class="reference internal" href="#libraries">10.2. Libraries</a></li>
<li><a class="reference internal" href="#shared-libraries">10.3. Shared libraries</a></li>
<li><a class="reference internal" href="#scripts">10.4. Scripts</a></li>
<li><a class="reference internal" href="#symbolic-links">10.5. Symbolic links</a></li>
<li><a class="reference internal" href="#device-files">10.6. Device files</a></li>
<li><a class="reference internal" href="#configuration-files">10.7. Configuration files</a><ul>
<li><a class="reference internal" href="#definitions">10.7.1. Definitions</a></li>
<li><a class="reference internal" href="#location">10.7.2. Location</a></li>
<li><a class="reference internal" href="#behavior">10.7.3. Behavior</a></li>
<li><a class="reference internal" href="#sharing-configuration-files">10.7.4. Sharing configuration files</a></li>
<li><a class="reference internal" href="#user-configuration-files-dotfiles">10.7.5. User configuration files (“dotfiles”)</a></li>
</ul>
</li>
<li><a class="reference internal" href="#log-files">10.8. Log files</a></li>
<li><a class="reference internal" href="#permissions-and-owners">10.9. Permissions and owners</a><ul>
<li><a class="reference internal" href="#the-use-of-dpkg-statoverride">10.9.1. The use of <code class="docutils literal notranslate">dpkg-statoverride</code></a></li>
</ul>
</li>
<li><a class="reference internal" href="#file-names">10.10. File names</a></li>
</ul>
</li>
</ul>

<h4>Previous topic</h4>
 <a href="ch-opersys.html"
 title="previous chapter">9. The Operating System</a>
 <h4>Next topic</h4>
 <a href="ch-customized-programs.html"
 title="next chapter">11. Customized programs</a>
 <div role="note" aria-label="source link">
 <h3>This Page</h3>
 <ul class="this-page-menu">
 <li><a href="_sources/ch-files.rst.txt"
 rel="nofollow">Show Source</a></li>
 </ul>
 </div>
<div id="searchbox" style="display: none" role="search">
 <h3 id="searchlabel">Quick search</h3>
 <div class="searchformwrapper">
 <form class="search" action="search.html" method="get">
 <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
 <input type="submit" value="Go" />
 </form>
 </div>
</div>
<script>$('#searchbox').show(0);</script>
 </div>
 </div>
 <div class="clearer"></div>
 </div>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="genindex.html" title="General Index"
 >index</a></li>
 <li class="right" >
 <a href="ch-customized-programs.html" title="11. Customized programs"
 >next</a> |</li>
 <li class="right" >
 <a href="ch-opersys.html" title="9. The Operating System"
 >previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">10. Files</a></li> 
 </ul>
 </div>
 <div class="footer" role="contentinfo">
 Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 4.2.0.
 </div>
 </body>
</html>

${this.title}

Code Editor : ch-files.html