</p>
</item>
<item>
-
<p>
The new package's files are unpacked, overwriting any
that may be on the system already, for example any
</item>
<item>
-
- <p><enumlist>
+ <p>
+ <enumlist>
<item>
<p>If the package is being upgraded, call
<example compact="compact">
<var>old-postrm</var> upgrade <var>new-version</var>
- </example></p>
+ </example>
+ </p>
</item>
<item>
<p>If this fails, <prgn>dpkg</prgn> will attempt:
</p>
</item>
</enumlist>
+ </p>
<p>
This is the point of no return - if
<prgn>dpkg</prgn> gets this far, it won't back off
</p>
</sect>
- <sect><heading>Details of configuration</heading>
+ <sect id="configdetails"><heading>Details of configuration</heading>
<p>
When we configure a package (this happens with <tt>dpkg
- --install</tt>, or with <tt>--configure</tt>), we first
+ --install</tt> and <tt>dpkg --configure</tt>), we first
update any <tt>conffile</tt>s and then call:
<example compact="compact">
<var>postinst</var> configure <var>most-recently-configured-version</var>
</p>
</sect>
- <sect><heading>Details of removal and/or configuration purging
- </heading>
+ <sect id="removedetails"><heading>Details of removal and/or
+ configuration purging</heading>
<p>
<enumlist>
</item>
<item>
<p>
- The conffiles and any backup files (<tt>~</tt>-files,
- <tt>#*#</tt> files, <tt>%</tt>-files,
- <tt>.dpkg-{old,new,tmp}</tt>, etc.) are removed.</p>
+ The <tt>conffile</tt>s and any backup files
+ (<tt>~</tt>-files, <tt>#*#</tt> files,
+ <tt>%</tt>-files, <tt>.dpkg-{old,new,tmp}</tt>, etc.)
+ are removed.</p>
</item>
<item>
<p>
</p>
</footnote>
must call <prgn>ldconfig</prgn> in its <prgn>postinst</prgn>
- script if and only if the first argument is <tt>configure</tt>
- and should call it in the <prgn>postrm</prgn> script if the
- first argument is <tt>remove</tt>.
+ script if the first argument is <tt>configure</tt> and should
+ call it in the <prgn>postrm</prgn> script if the first
+ argument is <tt>remove</tt>.
</p>
<p>
scripts whose values control the bahaviour of the scripts,
and which a system administrator is likely to want to
change. As the scripts themselves are frequently
- <tt>conffiles</tt>, modifying them requires that the
+ <tt>conffile</tt>s, modifying them requires that the
administrator merge in their changes each time the package
is upgraded and the <tt>conffile changes</tt>. To ease
the burden on the system administrator, such configurable
<p>
<taglist>
<tag>configuration file</tag>
- <item><p>
- A file that affects the operation of program, or
+ <item>
+ <p>
+ A file that affects the operation of a program, or
provides site- or host-specific information, or
- otherwise customizes the behavior of program.
+ 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 provide more
- useful site-specific behavior.</p>
+ desired) to conform to local policy or to provide
+ more useful site-specific behavior.
+ </p>
</item>
<tag><tt>conffile</tt></tag>
- <item><p>
+ <item>
+ <p>
A file listed in a package's <tt>conffiles</tt>
file, and is treated specially by <prgn>dpkg</prgn>
- (see the <em>Debian Packaging Manual</em>).</p>
+ (see <ref id="configdetails">).
+ </p>
</item>
</taglist>
</p>
<p>
The distinction between these two is important; they are
not interchangeable concepts. Almost all
- <tt>conffiles</tt> are configuration files, but many
- configuration files are not <tt>conffiles</tt>.</p>
+ <tt>conffile</tt>s are configuration files, but many
+ configuration files are not <tt>conffiles</tt>.
+ </p>
<p>
Note that a script that embeds configuration information
- (such as most of the files in <tt>/etc/init.d</tt> and
+ (such as most of the files in <tt>/etc/default</tt> and
<tt>/etc/cron.{daily,weekly,monthly}</tt>) is de-facto a
- configuration file and should be treated as such.</p>
+ configuration file and should be treated as such.
+ </p>
</sect1>
<sect1>
behavior:
<list compact="compact">
<item>
- <p>local changes must be preserved during a package
- upgrade</p>
+ <p>
+ local changes must be preserved during a package
+ upgrade, and
+ </p>
</item>
<item>
- <p>configuration files must be preserved when the
+ <p>
+ configuration files must be preserved when the
package is removed, and only deleted when the
- package is purged.</p>
+ package is purged.
+ </p>
</item>
- </list></p>
+ </list>
+ </p>
<p>
The easy way to achieve this behavior is to make the
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 different. The second is that
- <prgn>dpkg</prgn> might break the hard link while
- upgrading <tt>conffile</tt>s.
+ unwittingly become unlinked and different. The second
+ is that <prgn>dpkg</prgn> might break the hard link
+ while upgrading <tt>conffile</tt>s.
</p>
</footnote>
</p>
<p>
- The other way to do it is via the maintainer scripts.
- In this case, the configuration file must not be listed as
- a <tt>conffile</tt> and must not be part of the package
+ The other way to do it is via the maintainer scripts. In
+ this case, the configuration file must not be listed as a
+ <tt>conffile</tt> 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 write scripts
- which correctly create, update, maintain and
- remove-on-purge the file. These scripts must be idempotent
- (i.e., must work correctly if <prgn>dpkg</prgn> needs to
- re-run them due to errors during installation or removal),
- must cope with all the variety of ways <prgn>dpkg</prgn>
- 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 otherwise be good citizens.</p>
-
- <p>
- 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 <prgn>postinst</prgn> script.</p>
+ responsibility of the package maintainer to provide
+ maintainer scripts which correctly create, update and
+ maintain the file and remove it on purge. (See <ref
+ id="maintainerscripts"> for more information.) These
+ scripts must be idempotent (i.e., must work correctly if
+ <prgn>dpkg</prgn> needs to re-run them due to errors
+ during installation or removal), must cope with all the
+ variety of ways <prgn>dpkg</prgn> 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 otherwise be
+ good citizens.
+ </p>
- <p>
- A common practice is to create a script called
- <tt><var>package</var>-configure</tt> and have the
- package's <prgn>postinst</prgn> 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 <tt>/usr/share/<var>package</var></tt> or
- <tt>/usr/lib/<var>package</var></tt> with a symbolic link
- from <tt>/usr/share/doc/<var>package</var>/examples</tt>
- if they are examples, and should be
- perfectly ordinary <prgn>dpkg</prgn>-handled files
- (<em>not</em> <tt>conffiles</tt>).
- </p>
+ <p>
+ 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
+ <prgn>postinst</prgn> script.
+ </p>
+
+ <p>
+ A common practice is to create a script called
+ <tt><var>package</var>-configure</tt> and have the
+ package's <prgn>postinst</prgn> 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 <tt>/usr/share/<var>package</var></tt> or
+ <tt>/usr/lib/<var>package</var></tt> (depending on whether
+ they are architecture-independent or not). There should
+ be symbolic links to them from
+ <tt>/usr/share/doc/<var>package</var>/examples</tt> if
+ they are examples, and should be perfectly ordinary
+ <prgn>dpkg</prgn>-handled files (<em>not</em>
+ <tt>conffiles</tt>).
+ </p>
<p>
These two styles of configuration file handling must
not be mixed, for that way lies madness:
<prgn>dpkg</prgn> will ask about overwriting the file
- every time the package is upgraded.</p>
-
+ every time the package is upgraded.
+ </p>
</sect1>
<sect1>
<heading>Sharing configuration files</heading>
<p>
- Packages which specify the same file as
- `<tt>conffile</tt>' must be tagged as <em>conflicting</em>
- with each other.
- </p>
+ Packages which specify the same file as a
+ <tt>conffile</tt> must be tagged as <em>conflicting</em>
+ with each other. (This is an instance of the general rule
+ about not sharing files. Note that neither alternatives
+ nor diversions are likely to be appropriate in this case.)
+ </p>
<p>
- The maintainer scripts must not alter the conffile of
- <em>any</em> package, including the one the scripts belong
- to.</p>
+ The maintainer scripts must not alter a <tt>conffile</tt>
+ of <em>any</em> package, including the one the scripts
+ belong to.
+ </p>
<p>
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
<em>owner</em> of the configuration file, i.e., it will be
- the package to list that distributes the file and lists it
- as a <tt>conffile</tt>. 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.</p>
+ 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.</p>
<p>
If it is desirable for two or more related packages to
share a configuration file <em>and</em> for all of the
related packages to be able to modify that configuration
file, then the following should be done:
- <enumlist>
+ <enumlist compact="compact">
<item>
<p>
- have one of the related packages (the "core"
- package) manage the configuration file with
- maintainer scripts as described in the previous
- section.</p>
+ One of the related packages (the "owning" package)
+ will manage the configuration file with maintainer
+ scripts as described in the previous section.
+ </p>
</item>
- <item><p>
- the core package should also provide a program that
- the other packages may use to modify the
- configuration file.</p>
+ <item>
+ <p>
+ The owning package should also provide a program
+ that the other packages may use to modify the
+ configuration file.
+ </p>
</item>
<item>
<p>
- the related packages must use the provided program
- to make any 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.</p>
+ 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.)
+ </p>
</item>
- </enumlist></p>
+ </enumlist>
+ </p>
<p>
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. (Check
- out the <tt>sgml-base</tt> package as an example.)</p>
+ and which manages the shared configuration files. (The
+ <tt>sgml-base</tt> package is a good example.)
+ </p>
</sect1>
<sect1>
<heading>User configuration files ("dotfiles")</heading>
<p>
- Files in <tt>/etc/skel</tt> will automatically be copied
- into new user accounts by <prgn>adduser</prgn>. They
- should not be referenced there by any program.</p>
+ The files in <tt>/etc/skel</tt> will automatically be
+ copied into new user accounts by <prgn>adduser</prgn>.
+ No other program should reference the files in
+ <tt>/etc/skel</tt>.
+ </p>
<p>
Therefore, if a program needs a dotfile to exist in
advance in <tt>$HOME</tt> to work sensibly, that dotfile
- should be installed in <tt>/etc/skel</tt> (and listed in
- conffiles, if it is not generated and modified dynamically
- by the package's installation scripts).</p>
+ should be installed in <tt>/etc/skel</tt> and treated as a
+ configuration file.
+ </p>
<p>
However, programs that require dotfiles in order to
operate sensibly (dotfiles that they do not create
- themselves automatically, that is) are a bad thing, and
- programs should be configured by the Debian default
- installation as close to normal as possible.</p>
+ themselves automatically, that is) are a bad thing.
+ Furthermore, programs should be configured by the Debian
+ default installation as behave as closely to the upstream
+ default behaviour as possible.
+ </p>
<p>
Therefore, if a program in a Debian package needs to be
- configured in some way in order to operate sensibly that
- configuration should be done in a site-wide global
- configuration file elsewhere in <tt>/etc</tt>. 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
- <tt>/etc/skel</tt>.</p>
+ configured in some way in order to operate sensibly, that
+ should be done using a site-wide configuration file placed
+ in <tt>/etc</tt>. 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 <tt>/etc/skel</tt>.
+ </p>
<p>
<tt>/etc/skel</tt> should be as empty as we can make it.
- This is particularly true because there is no easy
- mechanism for ensuring that the appropriate dotfiles are
- copied into the accounts of existing users when a package
- is installed.</p>
+ 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.
+ </p>
</sect1>
</sect>
<sect>
<heading>Log files</heading>
- <p>
- 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.
- </p>
-
- <p>
- A better scheme is to use logrotate, a GPL'd program
- developed by Red Hat, which centralizes log management. It
- has both a configuration file (<tt>/etc/logrotate.conf</tt>)
- and a directory where packages can drop logrotation info
- (<tt>/etc/logrotate.d</tt>).
- </p>
-
<p>
Log files should usually be named
<tt>/var/log/<var>package</var>.log</tt>. If you have many
- log files, or need a separate directory for permissions
+ log files, or need a separate directory for permission
reasons (<tt>/var/log</tt> is writable only by
<tt>root</tt>), you should usually create a directory named
- <tt>/var/log/<var>package</var></tt>.</p>
+ <tt>/var/log/<var>package</var></tt> and place your log
+ files there.
+ </p>
<p>
- Log files must be rotated occasionally so
- that they don't grow indefinitely; the best way to do this
- is to drop a script into the directory
+ Log files must be rotated occasionally so that they don't
+ grow indefinitely; the best way to do this is to drop a log
+ rotation configuration file into the directory
<tt>/etc/logrotate.d</tt> and use the facilities provided by
- logrotate. Here is a good example for a logrotate config
+ logrotate.
+ <footnote>
+ <p>
+ The traditional approach to log files has been to set up
+ <em>ad hoc</em> 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.
+ </p>
+
+ <p>
+ The use of <prgn>logrotate</prgn>, a program developed
+ by Red Hat, is better, as it centralizes log management.
+ It has both a configuration file
+ (<tt>/etc/logrotate.conf</tt>) and a directory where
+ packages can drop their individual log rotation
+ configurations (<tt>/etc/logrotate.d</tt>).
+ </p>
+ </footnote>
+ Here is a good example for a logrotate config
file (for more information see <manref name="logrotate"
- section="8">):
+ section="8">):
<example compact="compact">
/var/log/foo/* {
rotate 12
endscript
}
</example>
- Which rotates all files under `/var/log/foo', saves 12
- compressed generations, and sends a HUP signal at the end of
- rotation.
-
+ This rotates all files under <tt>/var/log/foo</tt>, saves 12
+ compressed generations, and forces the daemon to reload its
+ configuration information after the log rotation.
</p>
<p>
Log files should be removed when the package is
- purged (but not when it is only removed), by checking the
- argument to the <prgn>postrm</prgn> script (see the <em>Debian
- Packaging Manual</em> for details).</p>
+ purged (but not when it is only removed). This should be
+ done by the <prgn>postrm</prgn> script when it is called
+ with the argument <tt>purge</tt> (see <ref
+ id="removedetails">).
+ </p>
</sect>
-
<sect>
<heading>Permissions and owners</heading>
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 should probably also
- discuss it on <prgn>debian-devel</prgn> first.</p>
+ discuss it on <prgn>debian-devel</prgn> first.
+ </p>
<p>
Files should be owned by <tt>root.root</tt>, and made
writable only by the owner and universally readable (and
- executable, if appropriate).</p>
+ executable, if appropriate), that is mode 644 or 755.
+ </p>
<p>
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.</p>
+ it.
+ </p>
<p>
Setuid and setgid executables should be mode 4755 or 2755
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
+ Debian package; it is merely inconvenient. For the same
reason you should not restrict read or execute permissions
- on non-set-id executables.</p>
+ on non-set-id executables.
+ </p>
<p>
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; there is no point in making
+ 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.</p>
+ execute them.
+ </p>
<p>
- You must not arrange that the system administrator can only
+ 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.
- Ordinary files installed by <prgn>dpkg</prgn> (as opposed
- to conffiles and other similar objects) have their
- permissions reset to the distributed permissions when the
- package is reinstalled. Instead you should consider (for
- example) creating a group for people allowed to use the
- program(s) and making any setuid executables executable
- only by that group.</p>
+ security policy by changing the permissions on a binary:
+ they can do this by using <prgn>dpkg-statoverride</prgn>, as
+ described below.
+ <footnote>
+ <p>
+ Ordinary files installed by <prgn>dpkg</prgn> (as
+ opposed to <tt>conffile</tt>s and other similar objects)
+ normally have their permissions reset to the distributed
+ permissions when the package is reinstalled. However,
+ the use of <prgn>dpkg-statoverride</prgn> overrides this
+ default behaviour. If you use this method, you should
+ remember to describe <prgn>dpkg-statoverride</prgn> in
+ the package documentation; being a relatively new
+ addition to Debian, it is probably not yet well-known.
+ </p>
+ </footnote>
+ 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.
+ </p>
<p>
If you need to create a new user or group for your package
<p>
If you need a statically allocated id, you must ask for a
- user or group id from the base system
- maintainer, and must not release the package until you
- have been allocated one. Once you have been allocated one
- you must make the package depend on a version of the base
- system with the id present in <tt>/etc/passwd</tt> or
- <tt>/etc/group</tt>, or alternatively arrange for your
- package to create the user or group itself with the
- correct id (using <tt>adduser</tt>) in its pre- or
- post-installation script (the latter is to be preferred if
- it is possible).</p>
-
- <p>
- On the other hand, the program might be able to determine the
- uid or gid from the group name at runtime, so that a
- dynamic id can be used. In this case you should choose an
- appropriate user or group name, discussing this on
- <prgn>debian-devel</prgn> and checking with the base
- system maintainer that it is unique and that they do not
- wish you to use a statically allocated id instead. When
- this has been checked you must arrange for your package to
- create the user or group if necessary using
- <prgn>adduser</prgn> in the pre- or post-installation
- script (again, the latter is to be preferred if it is
- possible).</p>
-
- <p>
- 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.</p>
+ user or group id from the <tt>base-passwd</tt> 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
+ <tt>base-passwd</tt> package with the id present in
+ <tt>/etc/passwd</tt> or <tt>/etc/group</tt>, or arrange for
+ your package to create the user or group itself with the
+ correct id (using <tt>adduser</tt>) in its
+ <prgn>preinst</prgn> or <prgn>postinst</prgn>. (Doing it in
+ the <prgn>postinst</prgn> is to be preferred if it is
+ possible, otherwise a pre-dependency will be needed on the
+ <tt>adduser</tt> package.)
+ </p>
+
+ <p>
+ 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 <prgn>debian-devel</prgn> and checking
+ with the base system maintainer that it is unique and that
+ they do not wish you to use a statically allocated id
+ instead. When this has been checked you must arrange for
+ your package to create the user or group if necessary using
+ <prgn>adduser</prgn> in the <prgn>preinst</prgn> or
+ <prgn>postinst</prgn> script (again, the latter is to be
+ preferred if it is possible).
+ </p>
+
+ <p>
+ 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.
+ </p>
+
+ <sect1><heading>The use of <prgn>dpkg-statoverride</prgn></heading>
+ <p>
+ This section is not intended as policy, but as a
+ description of the use of <prgn>dpkg-statoverride</prgn>.
+ </p>
+
+ <p>
+ <prgn>dpkg-statoverride</prgn> is a replacement for the
+ deprecated <tt>suidmanager</tt> package. Packages which
+ previously used <tt>suidmanager</tt> should have a
+ <tt>Conflicts: suidmanager (<< 0.50)</tt> entry (or even
+ <tt>(<< 0.52)</tt>), and calls to <tt>suidregister</tt>
+ and <tt>suidunregister</tt> should now be simply removed
+ from the maintainer scripts.
+ </p>
+
+ <p>
+ 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, he can use the <prgn>dpkg-statoverride</prgn>
+ program to instruct <prgn>dpkg</prgn> 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 <tt>.deb</tt>. 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 <tt>debconf</tt> to find out the
+ preference, and call <prgn>dpkg-statoverride</prgn> in the
+ maintainer script if necessary to accommodate the system
+ administrator's choice.
+ </p>
+
+ <p>
+ Given the above, <prgn>dpkg-statoverride</prgn> 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
+ <prgn>dpkg-statoverride</prgn> 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 <prgn>postinst</prgn>, where
+ <tt>sysuser</tt> is a dynamically allocated id:
+ <example>
+for i in /usr/bin/foo /usr/sbin/bar
+do
+ if ! dpkg-statoverride --list $i >/dev/null
+ then
+ dpkg-statoverride --update --add sysuser root 4755 $i
+ fi
+done
+ </example>
+ The corresponding <tt>dpkg-statoverride --remove</tt>
+ calls can then be made unconditionally when the package is
+ purged.
+ </p>
+ </sect1>
</sect>
</chapt>
projects / debian / debian-policy.git / commitdiff