+ udebs (stripped-down binary packages used by the Debian Installer) do
+ not comply with all of the requirements discussed here. See the
+
The Debian archive maintainers provide the authoritative list of sections. At present, they are: - admin, cli-mono, comm, database, - devel, debug, doc, editors, - education, electronics, embedded, - fonts, games, gnome, graphics, - gnu-r, gnustep, hamradio, haskell, - httpd, interpreters, introspection, - java, kde, kernel, libs, - libdevel, lisp, localization, - mail, math, metapackages, misc, - net, news, ocaml, oldlibs, - otherosfs, perl, php, python, - ruby, science, shells, sound, - tex, text, utils, vcs, - video, web, x11, xfce, - zope. The additional section debian-installer +admin, +cli-mono, +comm, +database, +debug, +devel, +doc, +editors, +education, +electronics, +embedded, +fonts, +games, +gnome, +gnu-r, +gnustep, +graphics, +hamradio, +haskell, +httpd, +interpreters, +introspection, +java, +kde, +kernel, +libdevel, +libs, +lisp, +localization, +mail, +math, +metapackages, +misc, +net, +news, +ocaml, +oldlibs, +otherosfs, +perl, +php, +python, +ruby, +science, +shells, +sound, +tasks, +tex, +text, +utils, +vcs, +video, +web, +x11, +xfce, +zope. + The additional section debian-installer contains special packages used by the installer and is not used for normal Debian packages.
@@ -848,10 +896,11 @@ Among those files are the package maintainer scripts and
Essential is defined as the minimal set of functionality that
must be available and usable on the system at all times, even
- when packages are in an unconfigured (but unpacked) state.
+ when packages are in the "Unpacked" state.
Packages are tagged essential for a system using the
Essential control field. The format of the
Essential control field is described in dpkg to stave off boredom on
- the part of a user installing many packages. This means,
- amongst other things, using the --quiet option on
-
@@ -1311,7 +1360,7 @@
installed together. If
The maintainer name and email address used in the changelog
- should be the details of the person uploading this
- version. They are not necessarily those of the
- usual package maintainer.
The following targets are required and must be implemented
by
+ For packages in the main archive, no required targets + may attempt network access. +
The targets are as follows: @@ -1946,51 +2003,33 @@
-- A package may also provide one or both of the targets - build-arch and build-indep. - The build-arch target, if provided, should + The build-arch target must perform all the configuration and compilation required for producing all architecture-dependant binary packages (those packages for which the body of the Architecture field in debian/control is not all). Similarly, the build-indep - target, if provided, should perform all the configuration + target must perform all the configuration and compilation required for producing all architecture-independent binary packages (those packages for which the body of the Architecture field in debian/control is all). -
- -
- If build-arch or build-indep targets are
- provided in the rules file, the build target
+ The build target
should either depend on those targets or take the same
actions as invoking those targets would perform.
- If one or both of the targets build-arch and
- build-indep are not provided, then invoking
-
The build-arch and build-indep targets must not do anything that might require root privilege. @@ -2129,7 +2168,7 @@
The architectures we build on and build for are determined
by
@@ -2524,7 +2562,9 @@ Package: libc6 the field name is Package and the field value libc6.
- + Empty field values are only permitted in source package control files
+ (
A paragraph must not contain more than one instance of a
particular field name.
@@ -2625,12 +2665,12 @@ Package: libc6
@@ -2701,6 +2744,7 @@ Package: libc6
The special value byhand for the section in a .changes file indicates that the file in question - is not an ordinary package file and must by installed by + is not an ordinary package file and must be installed by hand by the distribution maintainers. If the section is byhand the priority should be -.
@@ -3713,28 +3759,114 @@ Checksums-Sha256:
- In the
- Indicates that Debian Maintainers may upload this package to
- the Debian archive. The only valid value is yes. If
- the field DM-Upload-Allowed: yes is present in the
- source section of the source control file of the most recent
- version of a package in unstable or experimental, the Debian
- archive will accept uploads of this package signed with a key
- in the Debian Maintainer keyring. See the General
- Resolution
+ Debian source packages are increasingly developed using VCSs. The
+ purpose of the following fields is to indicate a publicly accessible
+ repository where the Debian source package is developed.
+
+
+ URL of a web interface for browsing the repository.
+
+ The field name identifies the VCS. The field's value uses the
+ version control system's conventional syntax for describing
+ repository locations and should be sufficient to locate the
+ repository used for packaging. Ideally, it also locates the
+ branch used for development of new versions of the Debian
+ package.
+
+ In the case of Git, the value consists of a URL, optionally
+ followed by the word -b and the name of a branch in
+ the indicated repository, following the syntax of the
+ git clone command. If no branch is specified, the
+ packaging should be on the default branch.
+
+ More than one different VCS may be specified for the same
+ package.
+
+ Multiline field listing all the packages that can be built from
+ the source package, considering every architecture. The first line
+ of the field value is empty. Each one of the next lines describes
+ one binary package, by listing its name, type, section and priority
+ separated by spaces. Fifth and subsequent space-separated items
+ may be present and parsers must allow them. See the
+
+ Simple field containing a word indicating the type of package: + deb for binary packages and udeb for micro binary + packages. Other types not defined here may be indicated. In + source package control files, the Package-Type field + should be omitted instead of giving it a value of deb, as + this value is assumed for paragraphs lacking this field. +
++ Folded field containing a single git commit hash, presented in + full, followed optionally by whitespace and other data to be + defined in future extensions. +
+ +
+ Declares that the source package corresponds exactly to a
+ referenced commit in a Git repository available at the canonical
+ location called dgit-repos, used by
+ The following fields have been obsoleted and may be found in packages + conforming with previous versions of the Policy. +
+ +
+ Indicates that Debian Maintainers may upload this package to
+ the Debian archive. The only valid value is yes. This
+ field was used to regulate uploads by Debian Maintainers, See the
+ General Resolution
The new package's status is now sane, and recorded as - "unpacked". + "Unpacked".
@@ -4472,7 +4625,7 @@ fi
No attempt is made to unwind after errors during configuration. If the configuration fails, the package is in - a "Failed Config" state, and an error message is generated. + a "Half-Configured" state, and an error message is generated.
@@ -4592,8 +4745,8 @@ fi dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols |. In such a case, - if any one of the alternative packages is installed, that - part of the dependency is considered to be satisfied. + that part of the dependency can be satisfied by any one of + the alternative packages.
@@ -4607,13 +4760,13 @@ fi
The relations allowed are <<, <=,
- =, >= and >> for
- strictly earlier, earlier or equal, exactly equal, later or
- equal and strictly later, respectively. The deprecated
- forms < and > were used to mean
- earlier/later or equal, rather than strictly earlier/later,
- so they should not appear in new packages (though
-
@@ -4677,7 +4830,8 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
- For binary relationship fields, the architecture restriction
+ For binary relationship fields and the Built-Using
+ field, the architecture restriction
syntax is only supported in the source package control
file
+ Some binary packages incorporate parts of other packages when built + but do not have to depend on those packages. Examples include + linking with static libraries or incorporating source code from + another package during the build. In this case, the source packages + of those other packages are a required part of the complete source + (the binary package is not reproducible without them). +
+ +
+ A Built-Using field must list the corresponding source
+ package for any such binary package incorporated during the build
+
+ A package using the source code from the gcc-4.6-source
+ binary package built from the gcc-4.6 source package would
+ have this field in its control file:
+
+ A package including binaries from grub2 and loadlin would
+ have this field in its control file:
+
+ To determine the soversion, look at + the SONAME of the library, stored in the + ELF SONAME attribute. It is usually of the + form name.so.major-version (for + example, libz.so.1). The version part is the part + which comes after .so., so in that example it + is 1. The soname may instead be of the + form name-major-version.so, such + as libdb-5.1.so, in which case the name would + be libdb and the version would be 5.1. +
+
If you have several shared libraries built from the same source
tree, you may lump them all together into a single shared
@@ -5538,9 +5751,8 @@ Replaces: mail-transport-agent
linked against the old shared library. Correct versioning of
dependencies on the newer shared library by binaries that use
the new interfaces is handled via
- the
@@ -5809,361 +6021,890 @@ Replaces: mail-transport-agent
-
If a package contains a binary or library which links to a
- shared library, we must ensure that when the package is
- installed on the system, all of the libraries needed are
- also installed. This requirement led to the creation of the
- shlibs system, which is very simple in its design:
- any package which provides a shared library also
- provides information on the package dependencies required to
- ensure the presence of this library, and any package which
- uses a shared library uses this information to
- determine the dependencies it requires. The files which
- contain the mapping from shared libraries to the necessary
- dependency information are called
- When a package is built which contains any shared libraries, it
- must provide a
+ shared library, we must ensure that, when the package is
+ installed on the system, all of the libraries needed are also
+ installed. These dependencies must be added to the binary
+ package when it is built, since they may change based on which
+ version of a shared library the binary or library was linked
+ with even if there are no changes to the source of the binary
+ (for example, symbol versions change, macros become functions or
+ vice versa, or the binary package may determine at compile-time
+ whether new library interfaces are available and can be called).
+ To allow these dependencies to be constructed, shared libraries
+ must provide either a
+ The two mechanisms differ in the degree of detail that they
+ provide. A
+ A
+
+
+ When a package that contains any shared libraries or compiled
+ binaries is built, it must run
+ If you are creating a udeb for use in the Debian Installer,
+ you will need to specify that
+
+ For more details on
+ We say that a binary foo directly uses a
+ library libbar if it is explicitly linked with that
+ library (that is, the library is listed in the
+ ELF NEEDED attribute, caused by adding -lbar
+ to the link line when the binary is created). Other libraries
+ that are needed by libbar are
+ linked indirectly to foo, and the dynamic
+ linker will load them automatically when it
+ loads libbar. A package should depend on the
+ libraries it directly uses, but not the libraries it only uses
+ indirectly. The dependencies for the libraries used
+ directly will automatically pull in the indirectly-used
+ libraries.
+ Maintaining a shared library package using
+ either
+ There are two types of ABI changes: ones that are
+ backward-compatible and ones that are not. An ABI change is
+ backward-compatible if any reasonable program or library that
+ was linked with the previous version of the shared library
+ will still work correctly with the new version of the shared
+ library.
+ ABI changes that are not backward-compatible normally require
+ changing the SONAME of the library and therefore the
+ shared library package name, which forces rebuilding all
+ packages using that shared library to update their
+ dependencies and allow them to use the new version of the
+ shared library. For more information,
+ see . The remainder of this
+ section will deal with backward-compatible changes.
+
+ Backward-compatible changes require either updating or
+ recording the minimal-version for that symbol
+ in
+ The easy case is when a public symbol is added. Simply add
+ the version at which the symbol was introduced
+ (for
+ A common example of when a change to the dependency version
+ is required is a function that takes an enum or struct
+ argument that controls what the function does. For example:
+
+ Dependency versions in either
+ In the following sections, we will first describe where the
+ various
+
+ During the package build, if the package itself
+ contains shared libraries with
+ These files must exist
+ before
+
+ Per-system overrides of shared library dependencies.
+ These files normally do not exist. They are
+ maintained by the local system administrator and must
+ not be created by any Debian package.
+
+ The
- We say that a binary foo directly uses
- a library libbar if it is explicitly linked
- with that library (that is, the library is listed in the ELF
- NEEDED attribute, caused by adding -lbar
- to the link line when the binary is created). Other
- libraries that are needed by libbar are linked
- indirectly to foo, and the dynamic
- linker will load them automatically when it loads
- libbar. A package should depend on the libraries
- it directly uses, but not the libraries it indirectly uses.
- The dependencies for those libraries will automatically pull
- in the other libraries.
+ Be aware that if a
- A good example of where this helps is the following. We
- could update libimlib with a new version that
- supports a new graphics format called dgf (but retaining the
- same major version number) and depends on libdgf.
- If we used
+
- In the following sections, we will first describe where the
- various shlibs files are to be found, then how to
- use
+ A
+
- There are several places where shlibs files are
- found. The following list gives them in the order in which
- they are read by
-
+ To explain this format, we'll use the the zlib1g
+ package as an example, which (at the time of writing)
+ installs the shared
+ library
-
+ library-soname must contain exactly the value of
+ the ELF SONAME attribute of the shared library. In
+ our example, this is libz.so.1.
- This lists overrides for this package. This file should
- normally not be used, but may be needed temporarily in
- unusual situations to work around bugs in other packages,
- or in unusual cases where the normally declared dependency
- information in the installed
+ main-dependency-template has the same syntax as a
+ dependency field in a binary package control file, except
+ that the string #MINVER# is replaced by a version
+ restriction like (>= version) or by
+ nothing if an unversioned dependency is deemed sufficient.
+ The version restriction will be based on which symbols from
+ the shared library are referenced and the version at which
+ they were introduced (see below). In nearly all
+ cases, main-dependency-template will
+ be package #MINVER#,
+ where package is the name of the binary package
+ containing the shared library. This adds a simple,
+ possibly-versioned dependency on the shared library package.
+ In some rare cases, such as when multiple packages provide
+ the same shared library ABI, the dependency template may
+ need to be more complex.
+
+ In our example, the first line of
+ the zlib1g
- This lists global overrides. This list is normally
- empty. It is maintained by the local system
- administrator.
-
+ Each public symbol exported by the shared library must have
+ a corresponding symbol line, indented by one
+ space. symbol is the exported symbol (which, for
+ C++, means the mangled symbol) followed by @ and
+ the symbol version, or the string Base if there is
+ no symbol version. minimal-version is the most
+ recent version of the shared library that changed the
+ behavior of that symbol, whether by adding it, changing its
+ function signature (the parameters, their types, or the
+ return type), or changing its behavior in a way that is
+ visible to a caller.
+ id-of-dependency-template is an optional
+ field that references
+ an alternative-dependency-template; see below for
+ a full description.
+
+ For example, libz.so.1 contains the
+ symbols compress
+ and compressBound. compress has no symbol
+ version and last changed its behavior in upstream
+ version 1:1.1.4. compressBound has the
+ symbol version ZLIB_1.2.0, was introduced in
+ upstream version 1:1.2.0, and has not changed its
+ behavior. Its
- When packages are being built,
- any
+ One or more alternative-dependency-template lines
+ may be provided. These are used in cases where some symbols
+ in the shared library should use one dependency template
+ while others should use a different template. The
+ alternative dependency templates are used only if a symbol
+ line contains the id-of-dependency-template
+ field. The first alternative dependency template is
+ numbered 1, the second 2, and so forth.
+ Finally, the entry for the library may contain one or more
+ metadata fields. Currently, the only
+ supported field-name
+ is Build-Depends-Package, whose value lists
+ the
- These are the
+ Also see
- This file lists any shared libraries whose packages
- have failed to provide correct
-
-
+ If your package provides a shared library, you should
+ arrange to include a
+ Normally, this is done by creating a
- Put a call to
-
+ Packages that provide
- This command puts the dependency information into the
-
- If you have multiple binary packages, you will need to call
-
+ The shlibs system is a simpler alternative to + the symbols system for declaring dependencies for + shared libraries. It may be more appropriate for C++ + libraries and other cases where tracking individual symbols is + too difficult. It predated the symbols system and is + therefore frequently seen in older packages. It is also + required for udebs, which do not support symbols. +
-
- If you are creating a udeb for use in the Debian Installer,
- you will need to specify that
+ In the following sections, we will first describe where the
+ various
- For more details on
+ There are several places where shlibs files are
+ found. The following list gives them in the order in which
+ they are read by
+ This lists overrides for this package. This file
+ should normally not be used, but may be needed
+ temporarily in unusual situations to work around bugs
+ in other packages, or in unusual cases where the
+ normally declared dependency information in the
+ installed
- Each
- We will explain this by reference to the example of the
- zlib1g package, which (at the time of writing)
- installs the shared library
+ This lists global overrides. This list is normally
+ empty. It is maintained by the local system
+ administrator.
+
- type is an optional element that indicates the type
- of package for which the line is valid. The only type currently
- in use is udeb. The colon and space after the type are
- required.
-
+ These files are generated as part of the package build
+ process and staged for inclusion as control files in
+ the binary packages being built. They provide details
+ of any shared libraries included in the same package.
+
- library-name is the name of the shared library,
- in this case libz. (This must match the name part
- of the soname, see below.)
-
+ The
- soname-version is the version part of the soname of
- the library. The soname is the thing that must exactly match
- for the library to be recognized by the dynamic linker, and is
- usually of the form
- name.so.major-version, in our
- example, libz.so.1.
+ This file lists any shared libraries whose packages
+ have failed to provide correct
+
+
- dependencies has the same syntax as a dependency - field in a binary package control file. It should give - details of which packages are required to satisfy a binary - built against the version of the library contained in the - package. See for details. -
+
+ If a
- In our example, if the first version of the zlib1g
- package which contained a minor number of at least
- 1.3 was 1:1.1.3-1, then the
- shlibs entry for this library could say:
-
- As zlib1g also provides a udeb containing the shared library,
- there would also be a second line:
-
+ Each
+ We will explain this by reference to the example of the
+ zlib1g package, which (at the time of writing)
+ installs the shared
+ library
- If your package provides a shared library, you need to create
- a
+ type is an optional element that indicates the + type of package for which the line is valid. The only type + currently in use is udeb. The colon and space + after the type are required. +
-
- As
+ library-name is the name of the shared library, + in this case libz. (This must match the name part + of the soname, see below.) +
+ ++ soname-version is the version part of the + ELF SONAME attribute of the library, determined the + same way that the soversion component of the + recommended shared library package name is determined. + See for the details. +
+ ++ dependencies has the same syntax as a dependency + field in a binary package control file. It should give + details of which packages are required to satisfy a binary + built against the version of the library contained in the + package. See for details on the + syntax, and for details on how + to maintain the dependency version constraint. +
+ +
+ In our example, if the last change to the zlib1g
+ package that could change behavior for a client of that
+ library was in version 1:1.2.3.3.dfsg-1, then
+ the shlibs entry for this library could say:
+
+ As zlib1g also provides a udeb containing the shared
+ library, there would also be a second line:
+
+ To provide a
+ Since
+ The FHS requirement that architecture-independent
+ application-specific static files be located in
+
The optional rules related to user specific
@@ -6226,8 +6981,18 @@ install -m644 debian/shlibs.package debian/package/DEBIAN/
+ The requirement for C and C++ headers files to be
+ accessible through the search path
+
@@ -6281,16 +7046,36 @@ install -m644 debian/shlibs.package debian/package/DEBIAN/
in
+ Packages must not assume the
+ The
- The following directories in the root filesystem are
- additionally allowed:
+ The requirement for
On GNU/Hurd systems, the following additional @@ -6571,6 +7356,35 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
+ This value must not be used, because it was + the error return sentinel value when uid_t + was 16 bits. +
+
+ Dynamically allocated user accounts. By
+ default
+ (uid_t)(-2) == (gid_t)(-2) must not be + used, because it is used as the anonymous, unauthenticated + user by some NFS implementations. +
+(uid_t)(-1) == (gid_t)(-1) must @@ -7369,33 +8183,28 @@ Reloading description configuration...done.
- Packages which provide the ability to view/show/play,
- compose, edit or print MIME types should register themselves
- as such following the current MIME support policy.
+ Packages which provide programs to view/show/play, compose, edit or
+ print MIME types should register them as such by placing a file in
+
The
- Packages containing such programs must register them
- with
+ A number of other init systems are available now in Debian that
+ can be used in place of
+ Packages may integrate with these replacement init systems by
+ providing implementation-specific configuration information about
+ how and when to start a service or in what order to run certain
+ tasks at boot time. However, any package integrating with other
+ init systems must also be backwards-compatible with
+
+ Packages may integrate with the
+ Because packages shipping upstart jobs may be installed on
+ systems that are not using upstart, maintainer scripts must
+ still use the common
+ Dependency-based boot managers for SysV init scripts, such as
+
+ 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
@@ -7760,8 +8647,9 @@ INSTALL = install -s # (or use strip on the files in debian/tmp)
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
@@ -8038,6 +8927,7 @@ fname () {
would point to
@@ -8070,7 +8960,9 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
- A symbolic link pointing to a compressed file should always
+ A symbolic link pointing to a compressed file (in the sense
+ that it is meant to be uncompressed with
@@ -8688,6 +9582,23 @@ done
+ ++ The name of the files installed by binary packages in the system PATH + (namely /bin, /sbin, /usr/bin, + /usr/sbin and /usr/games) 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. +
+Access to HTML documents
- -
- HTML documents for a package are stored in
-
- The web server should restrict access to the document - tree so that only clients on the same host can read - the documents. If the web server does not support such - access controls, then it should not provide access at - all, or ask about providing access during installation. -
+(Deleted)
The
+
+ Info readers requiring the
@@ -9762,45 +10662,77 @@ END-INFO-DIR-ENTRY
-
- Any additional documentation that comes with the package may
- be installed at the discretion of the package maintainer.
- Plain text documentation should be installed in the directory
-
- If a package comes with large amounts of documentation which - many users of the package will not require you should create - a separate binary package to contain it, so that it does not - take up disk space on the machines of users who do not need - or want it installed.
+ Plain text documentation should be compressed with gzip + -9 unless it is small. + + ++ If a package comes with large amounts of documentation that many + users of the package will not require, you should create a + separate binary package to contain it so that it does not take + up disk space on the machines of users who do not need or want + it installed. As a special case of this rule, shared library + documentation of any appreciable size should always be packaged + with the library development package () + or in a separate documentation package, since shared libraries + are frequently installed as dependencies of other packages by + users who have little interest in documentation of the library + itself. The documentation package for the + package package is conventionally + named package-doc + (or package-doc-language-code if there are + separate documentation packages for multiple languages). +
- It is often a good idea to put text information files
- (
+ Any separate package providing documentation must still install
+ standard documentation files in its
+ own
Packages must not require the existence of any files in
@@ -9820,18 +10752,6 @@ END-INFO-DIR-ENTRY
- -
- Former Debian releases placed all additional documentation
- in
- If your package comes with extensive documentation in a
+ If the package comes with extensive documentation in a
markup format that can be converted to various other formats
you should if possible ship HTML versions in a binary
- package, in the directory
-
@@ -9935,6 +10855,10 @@ END-INFO-DIR-ENTRY
+ All copyright files must be encoded in UTF-8. +
+
- It also documents the interaction between
-
This manual does not go into detail about the options and usage of the package building and installation tools. It @@ -10103,10 +11021,7 @@ END-INFO-DIR-ENTRY
The utility programs which are provided with
@@ -10126,25 +11041,9 @@ END-INFO-DIR-ENTRY
- The binary package has two main sections. The first part
- consists of various control information files and scripts used
- by
- The second part is an archive containing the files and - directories to be installed. -
- -
- In the future binary packages may also contain other
- components, such as checksums and digital signatures. The
- format for the archive is described in full in the
-
-
- It is usually invoked by hand from the top level of the
- built or unbuilt source directory. It may be invoked with
- no arguments; useful arguments include:
-
- Do not sign the .changes file or the
- source package .dsc file, respectively.
- Invoke sign-command instead of finding
- gpg or pgp on the
- When root privilege is required, invoke the command
- root-command. root-command
- should invoke its first argument as a command, from
- the
- Two types of binary-only build and upload - see
-
- This program is usually called from
- Its arguments are executables and shared libraries
-
- They may be specified either in the locations in the
- source tree where they are created or in the locations
- in the temporary build tree where they are installed
- prior to binary package creation.
-
- If some of the found shared libraries should only - warrant a Recommends or Suggests, or if - some warrant a Pre-Depends, this can be achieved - by using the -ddependency-field option - before those executable(s). (Each -d option - takes effect until the next -d.) -
- -
-
- For example, a package that generates an essential part
- which requires dependencies, and optional parts that
- which only require a recommendation, would separate those
- two sets of dependencies into two different fields.
- Sources which produce several binary packages with
- different shared library dependency requirements can use
- the -pvarnameprefix option to override
- the default shlibs: prefix (one invocation of
-
- This program is usually called by package-independent
- automatic building scripts such as
-
- It is usually called in the top level of a built source
- tree, and when invoked with no arguments will print out a
- straightforward
- This program is used internally by
-
- This program can be used manually, but is also invoked by
- dpkg-buildpackage or
+ Do not attempt to divert a conffile, as