[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian Policy Manual
Chapter 9 - The Operating System

9.1 File system hierarchy

9.1.1 File System Structure

The location of all files and directories must comply with the Filesystem Hierarchy Standard (FHS), version 2.3, 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.

  1. 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.

  1. The requirement for amd64 to use /lib64 for 64 bit binaries is removed.

  1. 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. [78]

    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. [79]

    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.

  1. The requirement that /usr/local/share/man be "synonymous" with /usr/local/man is relaxed to a recommendation

  1. The requirement that windowmanagers 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.

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

  1. The additional directory /run in the root file system is allowed. /run replaces /var/run, and the subdirectory /run/lock replaces /var/lock, with the /var directories replaced by symlinks for backwards compatibility. /run and /run/lock must follow all of the requirements in the FHS for /var/run and /var/lock, respectively, such as file naming conventions, file format requirements, or the requirement that files be cleared during the boot process. Files and directories residing in /run should be stored on a temporary file system.

    Packages must not assume the /run directory exists or is usable without a dependency on initscripts (>= 2.88dsf-13.3) until the stable release of Debian supports /run.

  1. The /sys directory in the root filesystem is additionally allowed. [80]

  1. The /var/www directory is additionally allowed.

  1. The requirement for /usr/local/lib<qual> to exist if /lib<qual> or /usr/lib<qual> exists (where lib<qual> is a variant of lib such as lib32 or lib64) is removed.

  1. On GNU/Hurd systems, the following additional directories are allowed in the root filesystem: /hurd and /servers.[81]

The version of this document referred here can be found in the debian-policy package or on FHS (Debian copy) alongside this manual (or, if you have the debian-policy installed, you can try FHS (local copy)). The latest version, which may be a more recent version, may be found on FHS (upstream). 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 for more information).

9.1.2 Site-specific programs

As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts.

However, the package may create empty directories below /usr/local so that the system administrator knows where to place site-specific files. These are not directories in /usr/local, but are children of directories in /usr/local. These directories (/usr/local/*/dir/) should be removed on package removal if they are empty.

Note that this applies only to directories below /usr/local, not in /usr/local. Packages must not create sub-directories in the directory /usr/local itself, except those listed in FHS, section 4.5. However, you may create directories below them as you wish. You must not remove any of the directories listed in 4.5, even if you created them.

Since /usr/local can be mounted read-only from a remote server, these directories must be created and removed by the postinst and prerm maintainer scripts and not be included in the .deb archive. These scripts must not fail if either of these operations fail.

For example, the emacsen-common package could contain something like

     if [ ! -e /usr/local/share/emacs ]; then
       if mkdir /usr/local/share/emacs 2>/dev/null; then
         if chown root:staff /usr/local/share/emacs; then
           chmod 2775 /usr/local/share/emacs || true

in its postinst script, and

     rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
     rmdir /usr/local/share/emacs 2>/dev/null || true

in the prerm script. (Note that this form is used to ensure that if the script is interrupted, the directory /usr/local/share/emacs will still be removed.)

If you do create a directory in /usr/local for local additions to a package, you should ensure that settings in /usr/local take precedence over the equivalents in /usr.

However, because /usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation.

The /usr/local directory itself and all the subdirectories created by the package should (by default) have permissions 2775 (group-writable and set-group-id) and be owned by root:staff.

9.1.3 The system-wide mail directory

The system-wide mail directory is /var/mail. This directory is part of the base system and should not be owned by any particular mail agents. The use of the old location /var/spool/mail is deprecated, even though the spool may still be physically located there.

9.1.4 /run and /run/lock

The directory /run is cleared at boot, normally by being a mount point for a temporary file system. Packages therefore must not assume that any files or directories under /run other than /run/lock exist unless the package has arranged to create those files or directories since the last reboot. Normally, this is done by the package via an init script. See Writing the scripts, Section for more information.

Packages must not include files or directories under /run, or under the older /var/run and /var/lock paths. The latter paths will normally be symlinks or other redirections to /run for backwards compatibility.

9.2 Users and groups

9.2.1 Introduction

The Debian system can be configured to use either plain or shadow passwords.

Some user ids (UIDs) and group ids (GIDs) are reserved globally for use by certain packages. Because some packages need to include files which are owned by these users or groups, or need the ids compiled into binaries, these ids must be used on any Debian system only for the purpose for which they are allocated. This is a serious restriction, and we should avoid getting in the way of local administration policies. In particular, many sites allocate users and/or local system groups starting at 100.

Apart from this we should have dynamically allocated ids, which should by default be arranged in some sensible order, but the behavior should be configurable.

Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow.

9.2.2 UID and GID classes

The UID and GID numbers are divided into classes as follows:


Globally allocated by the Debian project, the same on every Debian system. These ids will appear in the passwd and group files of all Debian systems, new ids in this range being added automatically as the base-passwd package is updated.

Packages which need a single statically allocated uid or gid should use one of these; their maintainers should ask the base-passwd maintainer for ids.


Dynamically allocated system users and groups. Packages which need a user or group, but can have this user or group allocated dynamically and differently on each system, should use adduser --system to create the group and/or user. adduser will check for the existence of the user or group, and if necessary choose an unused id based on the ranges specified in adduser.conf.


Dynamically allocated user accounts. By default adduser will choose UIDs and GIDs for user accounts in this range, though adduser.conf may be used to modify this behavior.


Globally allocated by the Debian project, but only created on demand. The ids are allocated centrally and statically, but the actual accounts are only created on users' systems on demand.

These ids are for packages which are obscure or which require many statically-allocated ids. These packages should check for and create the accounts in /etc/passwd or /etc/group (using adduser if it has this facility) if necessary. Packages which are likely to require further allocations should have a "hole" left after them in the allocation, to give them room to grow.




User nobody. The corresponding gid refers to the group nogroup.


(uid_t)(-1) == (gid_t)(-1) must not be used, because it is the error return sentinel value.

9.3 Init systems

The default init system in Debian with Linux kernels is systemd, run when systemd-sysv is installed. A number of other init systems are available in Debian, including in particular System V init, run when sysvinit-core is installed (and also the default for non-Linux kernels). Both of these packages provide the init metapackage.

Packages must integrate with the default init system and may integrate with others as well.

These files provide init-system-specific information about how and when to run services, about boot-time and shutdown-time "milestones" or "targets", and about tasks that run as part of the boot-up or shutdown procedures. [82]

The least common denominator of these are the init.d scripts. systemd places restrictions upon them, forbidding some of the more esoteric possible mechanisms that System V init historically allowed. However, a script that is compliant with this Policy should be usable with systemd. [83]

Packages should use the same names for files across different init systems. However, this is not always possible. For example, an init.d script can start and manage several services, whereas one would have individual systemd unit files for each of the individual services (and possibly more unit files for sockets if the services are socket-activated). Similarly, packages may be constrained by what upstream does. It is recommended that packages adopt the same names, though; not the least because this enables a package to take advantage of the fact that a systemd unit file that shares a name with a init.d script will be used in preference to that script. [84]

9.3.1 systemd unit files

The /usr/lib/systemd/system directory contains (package-supplied) systemd unit files that define systemd-managed services, sockets, mount points, automount entries, and other items. Administrators do not make local modifications to these files.

Instead, local modifications made by administrators take the form of files in the /etc/systemd/system directory, which override package-supplied units entirely, and files in *.conf subdirectories of that directory, which override parts of the package-supplied units. (See systemd.unit(8).) Conversely, packages must not make modifications to these files.

A limited exception to this rule is that packages are permitted to make once-off conversions, during an upgrade, from information in a /etc/defaults/package file to systemd unit override snippets in /etc/systemd/system/*/*.conf files. [85]

The requirements of /run and /run/lock, Section 9.1.4 apply to unit files under /run/systemd of course.

For details of unit files please consult the man pages systemd.unit(8), systemd.exec(8), systemd.service(8), systemd.socket(8), and systemd.target(8). constraints upon unit files recommendations for unit files

9.3.2 non-unit systemd-related package files

Packages can ship additional items for systemd, including tmpfiles.d files, sysctl.d files, and binfmt.d files amonst others. Packages must not ship any such files under /etc, nor may they make any modifications to such files under /etc. The files in that subtree are the province of the local system administrator. All such files must be shipped in the appropriate subdirectories of /usr/lib.

These or work-alike mechanisms may not be available with other init systems. However, Policy does not exclude packages from using, and depending upon, a (hypothetical example) upstart-tmpfilesd for achieving the same ends when integrated with the upstart init system.

9.3.3 upstart job files

The /etc/init directory contains job files used by the the upstart init system.

Dependency-based boot managers for init.d scripts, such as startpar, may avoid running a given script entirely when an equivalent upstart job is present, to avoid unnecessary forking of no-op init scripts. In this case, the boot manager should integrate with upstart to detect when the upstart job in question is started or stopped to know when the dependency has been satisfied.

Other interactions between init.d scripts and upstart are described at init.d scripts, Section 9.3.7.

9.3.4 runlevels and /etc/inittab

System V init's configuration file is /etc/inittab, which describes a set of "runlevels" and the default runlevel that the system boots into. systemd has a mechanism that emulates System V init runlevels, but no init system other than Systemm V init uses or supplies the /etc/inittab file itself. In order to operate correctly with the (Linux) default and indeed all but one of the init systems, packages must not use /etc/inittab.

Maintainer scripts may not assume that a distinct current run level can be determined; because this is not necessarily the case with the default init system. In general, maintainer scripts should avoid any mention of run levels at all. [88]

9.3.5 BSD-style rc: rc.boot and rc.local

Two Debian bootstrap mechanisms have their roots in non-System-V bootstrap mechanisms, the /etc/rc.local file and the /etc/rc.boot directory. The latter was a place where scripts to be run at boot-up could be placed. [89] It is entirely deprecated and packages must not use it. No Debian init system now supports this mechanism.

Packages must not use the former; as the name suggests it is for local administrator bootstrap tasks. Both systemd and System V init will run an rc.local file if it exists and is executable as a program. [90]

9.3.6 System V rc

System V init implements changing between run levels through one of several rc programs which in turn invoke init.d scripts (described in init.d scripts, Section 9.3.7). Packages that wish to provide the System V rc interface to the System V init system must provide the following programs:

All init systems must provide the latter two, either themselves or through cooperation with an rc package. Only System V init itself also requires the former two from rc packages.

There are three different rc packages in Debian, sysv-rc, file-rc, and openrc. These record what scripts are enabled in each runlevel in differing ways. Please refer to their documentation for the details. systemd has a fourth mechanism that is largely compatible with sysv-rc, but which has several differences, such as masking and the overriding priority that is given to service units.

In general, therefore, maintainer scripts must not assume that the symbolic link mechanisms (described in previous editions of the Debian Policy Manual) take effect or even exist at all. Maintainer scripts scripts such as postinst, prerm and postrm. must use only the supplied update-rc.d and invoke-rc.d programs for interacting with the init.d script system.

Only the rc packages themselves, and their various adjunct packages, have any business (in maintainer scripts) with the /etc/rcn.d directories (of openrc and sysv-rc) or the /etc/runlevel.conf file (of file-rc). systemd and upstart and rc

In Debian 8, systemd and upstart do not provide their own invoke-rc.d and update-rc.d. The commands in the sysv-rc package have been augmented to detect the running init system and take the appropriate actions for enabling, disabling, starting, and stopping services. These augmentations do not exist in the invoke-rc.d and update-rc.d in the file-rc and openrc packages.

Administrators are encouraged to prefer the service command to invoking init.d scripts directly, because it attempts to minimize (even though it cannot totally eradicate) the amount of login session state, including settings that can potentially break service operations, that leaks from the administrator's shell running the service command to the daemon process(es) started by the init.d script. Better still is to use the systemctl or initctl commands, of course.

init.d scripts for which an equivalent upstart job is available must query the output of the command initctl version for the string upstart and avoid running in favor of the native upstart job, using a test such as this:

     if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart
     	exit 1

Avoiding running in favour of a native systemd unit is slightly simpler. If an init.d script sources /lib/lsb/init-functions, the script will automatically redirect invocations to systemctl. Enabling and disabling scripts with update-rc.d

The program update-rc.d is provided (by each init/rc system) for package maintainers to arrange for enabling and disabling the running of init.d scripts. This may be used by maintainers in their packages' postinst and postrm scripts. Maintainer scripts must not attempt to enable and disable scripts directly.

By default update-rc.d will enable services in the multi-user state, meaning that they will be started in that state and stopped in the halt, rescue, poweroff, and reboot states.

To get the default behavior for your package, put

     		update-rc.d package defaults

in your postinst script and put

     		if [ "$1" = purge ]; then
     		update-rc.d package remove

in your postrm.

For more information about using update-rc.d, please consult its man page update-rc.d(8). Starting and stopping scripts with invoke-rc.d

The program invoke-rc.d is provided for properly invoking an init.d script, obeying runlevels, masks, and other init-system-defined and locally-defined constraints that might limit a package's right to start, stop and otherwise manage services. Maintainer scripts must use this program and must not attempt to enable and disable scripts directly.

For compatibility with the default init system, maintainer scripts must not run invoke-rc.d with any action requests other than the conventional start, stop, reload, force-reload, and restart.

Instead of using:

     /etc/init.d/<package> <action>

in a package's postinst and prerm scripts packages must have something like:

     if which invoke-rc.d >/dev/null 2>&1; then
     	invoke-rc.d package <action>
     	/etc/init.d/package <action>

A package should register its init.d services using update-rc.d before it tries to invoke them using invoke-rc.d. Invocation of unregistered services may fail on some init systems.

For more information about using invoke-rc.d, please consult its man page invoke-rc.d(8).

9.3.7 init.d scripts

The /etc/init.d directory contains scripts that are executed directly by systemd and upstart, and indirectly by System V init by way of one of several rc systems (described in System V rc, Section 9.3.6). Writing the scripts

Packages that include daemons for system services may place scripts in /etc/init.d to start or stop services at boot time or during a change of runlevel. These scripts should be named /etc/init.d/package, and they should accept one argument, saying what to do:


start the service,


stop the service,


stop and restart the service if it's already running, otherwise start the service


cause the configuration of the service to be reloaded without actually stopping and restarting the service,


cause the configuration to be reloaded if the service supports this, otherwise restart the service.

The start, stop, restart, and force-reload options should be supported by all scripts in /etc/init.d, the reload option is optional.

An example on which you can base your /etc/init.d scripts is found in /etc/init.d/skeleton.

The init.d scripts must ensure that they will behave sensibly (i.e., returning success and not starting multiple copies of a service) if invoked with start when the service is already running, or with stop when it isn't, and that they don't kill unfortunately-named user processes. The best way to achieve this is to switch from an init.d script to a service unit (systemd unit files, Section 9.3.1) or a job file (upstart job files, Section 9.3.3) of course. Whilst remaining an init.d script however, the best usually for achieving this is to use start-stop-daemon with the --oknodo option.

Be careful of using set -e in init.d scripts. Writing correct init.d scripts requires accepting various error exit statuses when daemons are already running or already stopped without aborting the init.d script, and common init.d function libraries are not safe to call with set -e in effect[91]. For init.d scripts, it's often easier to not use set -e and instead check the result of each command separately.

If a service reloads its configuration automatically (as in the case of cron, for example), the reload option of the init.d script should behave as if the configuration has been reloaded successfully.

The /etc/init.d scripts must be treated as configuration files, either (if they are present in the package, that is, in the .deb file) by marking them as conffiles, or, (if they do not exist in the .deb) by managing them correctly in the maintainer scripts (see Configuration files, Section 10.7). This is important since we want to give the local system administrator the chance to adapt the scripts to the local system, e.g., to disable a service without de-installing the package, or to specify some special command line options when starting a service, while making sure their changes aren't lost during the next package upgrade.

These scripts should not fail obscurely when the configuration files remain but the package has been removed, as configuration files remain on the system after the package has been removed. Only when dpkg is executed with the --purge option will configuration files be removed. In particular, as the /etc/init.d/package script itself is usually a conffile, it will remain on the system if the package is removed but not purged. Therefore, you should include a test statement at the top of the script, like this:

     test -f program-executed-later-in-script || exit 0

Often there are some variables in the init.d scripts whose values control the behavior of the scripts, and which a system administrator is likely to want to change. As the scripts themselves are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. Instead, they should be placed in a file in /etc/default, which typically will have the same base name as the init.d script. This extra file should be sourced by the script when the script runs. It must contain only variable settings and comments in SUSv3 sh format. It may either be a conffile or a configuration file maintained by the package maintainer scripts. See Configuration files, Section 10.7 for more details.

To ensure that vital configurable values are always available, the init.d script should set default values for each of the shell variables it uses, either before sourcing the /etc/default/ file or afterwards using something like the : ${VAR:=default} syntax. Also, the init.d script must behave sensibly and not fail if the /etc/default file is deleted.

Files and directories under /run, including ones referred to via the compatibility paths /var/run and /var/lock, are normally stored on a temporary filesystem and are normally not persistent across a reboot. The init.d scripts must handle this correctly. This will typically mean creating any required subdirectories dynamically when the init.d script is run. See /run and /run/lock, Section 9.1.4 for more information. Console messages from init.d scripts

This section describes the formats to be used for messages written to standard output by the /etc/init.d scripts. The intent is to improve the consistency of Debian's startup and shutdown look and feel. For this reason, please look very carefully at the details. We want the messages to have the same format in terms of wording, spaces, punctuation and case of letters.

Here is a list of overall rules that should be used for messages generated by /etc/init.d scripts.

init.d script should use the following standard message formats for the situations enumerated below.

9.4 Cron jobs

Packages must not modify the configuration file /etc/crontab, and they must not modify the files in /var/spool/cron/crontabs.

If a package wants to install a job that has to be executed via cron, it should place a file named as specified in Cron job file names, Section 9.4.1 into one or more of the following directories:


As these directory names imply, the files within them are executed on an hourly, daily, weekly, or monthly basis, respectively. The exact times are listed in /etc/crontab.

All files installed in any of these directories must be scripts (e.g., shell scripts or Perl scripts) so that they can easily be modified by the local system administrator. In addition, they must be treated as configuration files.

If a certain job has to be executed at some other frequency or at a specific time, the package should install a file in /etc/cron.d with a name as specified in Cron job file names, Section 9.4.1. This file uses the same syntax as /etc/crontab and is processed by cron automatically. The file must also be treated as a configuration file. (Note that entries in the /etc/cron.d directory are not handled by anacron. Thus, you should only use this directory for jobs which may be skipped if the system is not running.)

Unlike crontab files described in the IEEE Std 1003.1-2008 (POSIX.1) available from The Open Group, the files in /etc/cron.d and the file /etc/crontab have seven fields; namely:

  1. Minute [0,59]

  1. Hour [0,23]

  1. Day of the month [1,31]

  1. Month of the year [1,12]

  1. Day of the week ([0,6] with 0=Sunday)

  1. Username

  1. Command to be run

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive. Lists are allowed. A list is a set of numbers (or ranges) separated by commas. Step values can be used in conjunction with ranges.

The scripts or crontab entries in these directories should check if all necessary programs are installed before they try to execute them. Otherwise, problems will arise when a package was removed but not purged since configuration files are kept on the system in this situation.

Any cron daemon must provide /usr/bin/crontab and support normal crontab entries as specified in POSIX. The daemon must also support names for days and months, ranges, and step values. It has to support /etc/crontab, and correctly execute the scripts in /etc/cron.d. The daemon must also correctly execute scripts in /etc/cron.{hourly,daily,weekly,monthly}.

9.4.1 Cron job file names

The file name of a cron job file should normally match the name of the package from which it comes.

If a package supplies multiple cron job files files in the same directory, the file names should all start with the name of the package (possibly modified as described below) followed by a hyphen (-) and a suitable suffix.

A cron job file name must not include any period or plus characters (. or +) characters as this will cause cron to ignore the file. Underscores (_) should be used instead of . and + characters.

9.5 Menus

The Debian menu package provides a standard interface between packages providing applications and menu programs (either X window managers or text-based menu programs such as pdmenu).

All packages that provide applications that need not be passed any special command line arguments for normal operation should register a menu entry for those applications, so that users of the menu package will automatically get menu entries in their window managers, as well in shells like pdmenu.

Menu entries should follow the current menu policy.

The menu policy can be found in the menu-policy files in the debian-policy package. It is also available from the Debian web mirrors at /doc/packaging-manuals/menu-policy/.

Please also refer to the Debian Menu System documentation that comes with the menu package for information about how to register your applications.

9.6 Multimedia handlers

MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) is a mechanism for encoding files and data streams and providing meta-information about them, in particular their type (e.g. audio or video) and format (e.g. PNG, HTML, MP3).

Registration of MIME type handlers allows programs like mail user agents and web browsers to invoke these handlers to view, edit or display MIME types they don't support directly.

Packages which provide programs to view/show/play, compose, edit or print MIME types should register them as such by placing a file in mailcap(5) format (RFC 1524) in the directory /usr/lib/mime/packages/. The file name should be the binary package's name.

The mime-support package provides the update-mime program, which integrates these registrations in the /etc/mailcap file, using dpkg triggers[92]. Packages using this facility should not depend on, recommend, or suggest mime-support.

9.7 Keyboard configuration

To achieve a consistent keyboard configuration so that all applications interpret a keyboard event the same way, all programs in the Debian distribution must be configured to comply with the following guidelines.

The following keys must have the specified interpretations:


delete the character to the left of the cursor


delete the character to the right of the cursor


emacs: the help prefix

The interpretation of any keyboard events should be independent of the terminal that is used, be it a virtual console, an X terminal emulator, an rlogin/telnet session, etc.

The following list explains how the different programs should be set up to achieve this:

This will solve the problem except for the following cases:

9.8 Environment variables

A program must not depend on environment variables to get reasonable defaults. (That's because these environment variables would have to be set in a system-wide configuration file like /etc/profile, which is not supported by all shells.)

If a program usually depends on environment variables for its configuration, the program should be changed to fall back to a reasonable default configuration if these environment variables are not present. If this cannot be done easily (e.g., if the source code of a non-free program is not available), the program must be replaced by a small "wrapper" shell script which sets the environment variables if they are not already defined, and calls the original program.

Here is an example of a wrapper script for this purpose:

     export BAR
     exec /usr/lib/foo/foo "$@"

Furthermore, as /etc/profile is a configuration file of the base-files package, other packages must not put any environment variables or other commands into that file.

9.9 Registering Documents using doc-base

The doc-base package implements a flexible mechanism for handling and presenting documentation. The recommended practice is for every Debian package that provides online documentation (other than just manual pages) to register these documents with doc-base by installing a doc-base control file in /usr/share/doc-base/.

Please refer to the documentation that comes with the doc-base package for information and details.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian Policy Manual

version, 2014-11-21

The Debian Policy Mailing List