# SOME DESCRIPTIVE TITLE.
# Copyright (C) 1996, 1997, 1998 Ian Jackson, Christian Schwarz, 1998-2017,
# The Debian Policy Mailing List
# This file is distributed under the same license as the Debian Policy
# Manual package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2018.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Debian Policy Manual 4.1.6.0\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2021-08-17 20:06-0700\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.8.0\n"

#: ../../ch-sharedlibs.rst:2
msgid "Shared libraries"
msgstr ""

#: ../../ch-sharedlibs.rst:4
msgid ""
"Packages containing shared libraries must be constructed with a little "
"care to make sure that the shared library is always available. This is "
"especially important for packages whose shared libraries are vitally "
"important, such as the C library (currently ``libc6``)."
msgstr ""

#: ../../ch-sharedlibs.rst:9
msgid ""
"This section deals only with public shared libraries: shared libraries "
"that are placed in directories searched by the dynamic linker by default "
"or which are intended to be linked against normally and possibly used by "
"other, independent packages. Shared libraries that are internal to a "
"particular package or that are only loaded as dynamic modules are not "
"covered by this section and are not subject to its requirements."
msgstr ""

#: ../../ch-sharedlibs.rst:16
msgid ""
"A shared library is identified by the ``SONAME`` attribute stored in its "
"dynamic section. When a binary is linked against a shared library, the "
"``SONAME`` of the shared library is recorded in the binary's ``NEEDED`` "
"section so that the dynamic linker knows that library must be loaded at "
"runtime. The shared library file's full name (which usually contains "
"additional version information not needed in the ``SONAME``) is therefore"
" normally not referenced directly. Instead, the shared library is loaded "
"by its ``SONAME``, which exists on the file system as a symlink pointing "
"to the full name of the shared library. This symlink must be provided by "
"the package.  :ref:`s-sharedlibs-runtime` describes how to do this.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:27
msgid ""
"When linking a binary or another shared library against a shared library,"
" the ``SONAME`` for that shared library is not yet known. Instead, the "
"shared library is found by looking for a file matching the library name "
"with ``.so`` appended. This file exists on the file system as a symlink "
"pointing to the shared library."
msgstr ""

#: ../../ch-sharedlibs.rst:33
msgid ""
"Shared libraries are normally split into several binary packages. The "
"``SONAME`` symlink is installed by the runtime shared library package, "
"and the bare ``.so`` symlink is installed in the development package "
"since it's only used when linking binaries or shared libraries. However, "
"there are some exceptions for unusual shared libraries or for shared "
"libraries that are also loaded as dynamic modules by other programs."
msgstr ""

#: ../../ch-sharedlibs.rst:40
msgid ""
"This section is primarily concerned with how the separation of shared "
"libraries into multiple packages should be done and how dependencies on "
"and between shared library binary packages are managed in Debian. "
":ref:`s-libraries` should be read in conjunction with this section and "
"contains additional rules for the files contained in the shared library "
"packages."
msgstr ""

#: ../../ch-sharedlibs.rst:47
msgid ""
"This is a convention of shared library versioning, but not a requirement."
" Some libraries use the ``SONAME`` as the full library file name instead "
"and therefore do not need a symlink. Most, however, encode additional "
"information about backwards-compatible revisions as a minor version "
"number in the file name. The ``SONAME`` itself only changes when binaries"
" linked with the earlier version of the shared library may no longer "
"work, but the filename may change with each release of the library. See "
":ref:`s-sharedlibs-runtime` for more information."
msgstr ""

#: ../../ch-sharedlibs.rst:60
msgid "Run-time shared libraries"
msgstr ""

#: ../../ch-sharedlibs.rst:62
msgid ""
"The run-time shared library must be placed in a package whose name "
"changes whenever the ``SONAME`` of the shared library changes. This "
"allows several versions of the shared library to be installed at the same"
" time, allowing installation of the new version of the shared library "
"without immediately breaking binaries that depend on the old version. "
"[#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:68
msgid ""
"Normally, the run-time shared library and its ``SONAME`` symlink should "
"be placed in a package named libraryname\\ *soversion*, where *soversion*"
" is the version number in the ``SONAME`` of the shared library. "
"Alternatively, if it would be confusing to directly append *soversion* to"
" libraryname (if, for example, libraryname itself ends in a number), you "
"should use libraryname-\\ *soversion* instead. [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:75
msgid ""
"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``."
msgstr ""

#: ../../ch-sharedlibs.rst:83
msgid ""
"If you have several shared libraries built from the same source tree, you"
" may lump them all together into a single shared library package provided"
" that all of their ``SONAME``\\ s will always change together. Be aware "
"that this is not normally the case, and if the ``SONAME``\\ s do not "
"change together, upgrading such a merged shared library package will be "
"unnecessarily difficult because of file conflicts with the old version of"
" the package. When in doubt, always split shared library packages so that"
" each binary package installs a single shared library."
msgstr ""

#: ../../ch-sharedlibs.rst:92
msgid ""
"Every time the shared library ABI changes in a way that could break "
"binaries linked against older versions of the shared library, the "
"``SONAME`` of the library and the corresponding name for the binary "
"package containing the runtime shared library should change. Normally, "
"this means the ``SONAME`` should change any time an interface is removed "
"from the shared library or the signature of an interface (the number of "
"parameters or the types of parameters that it takes, for example) is "
"changed. This practice is vital to allowing clean upgrades from older "
"versions of the package and clean transitions between the old ABI and new"
" ABI without having to upgrade every affected package simultaneously."
msgstr ""

#: ../../ch-sharedlibs.rst:103
msgid ""
"The ``SONAME`` and binary package name need not, and indeed normally "
"should not, change if new interfaces are added but none are removed or "
"changed, since this will not break binaries 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 ``symbols`` or"
" ``shlibs`` system (see :ref:`s-sharedlibs-depends`)."
msgstr ""

#: ../../ch-sharedlibs.rst:110
msgid ""
"The package should install the shared libraries under their normal names."
" For example, the libgdbm3 package should install ``libgdbm.so.3.0.0`` as"
" ``/usr/lib/libgdbm.so.3.0.0``. The files should not be renamed or re-"
"linked by any ``prerm`` or ``postrm`` scripts; ``dpkg`` will take care of"
" renaming things safely without affecting running programs, and attempts "
"to interfere with this are likely to lead to problems."
msgstr ""

#: ../../ch-sharedlibs.rst:118
msgid ""
"Shared libraries should not be installed executable, since the dynamic "
"linker does not require this and trying to execute a shared library "
"usually results in a core dump."
msgstr ""

#: ../../ch-sharedlibs.rst:122
msgid ""
"The run-time library package should include the symbolic link for the "
"``SONAME`` that ``ldconfig`` would create for the shared libraries. For "
"example, the libgdbm3 package should include a symbolic link from "
"``/usr/lib/libgdbm.so.3`` to ``libgdbm.so.3.0.0``. This is needed so that"
" the dynamic linker (for example ``ld.so`` or ``ld-linux.so.*``) can find"
" the library between the time that ``dpkg`` installs it and the time that"
" ``ldconfig`` is run in the ``postinst`` script.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:130
msgid ""
"There are some exceptional situations in which co-installation of two "
"versions of a shared library is not safe, and the new shared library "
"package has to conflict with the previous shared library package. This is"
" never desirable, since it causes significant disruption during upgrades "
"and potentially breaks unpackaged third-party binaries, but is sometimes "
"unavoidable. These situations are sufficiently rare that they usually "
"warrant project-wide discussion, and are complex enough that the rules "
"for them cannot be codified in Debian Policy."
msgstr ""

#: ../../ch-sharedlibs.rst:140
msgid ""
"The following command, when run on a shared library, will output the name"
" to be used for the Debian package containing that shared library::"
msgstr ""

#: ../../ch-sharedlibs.rst:148
msgid ""
"The package management system requires the library to be placed before "
"the symbolic link pointing to it in the ``.deb`` file. This is so that "
"when ``dpkg`` comes to install the symlink (overwriting the previous "
"symlink pointing at an older version of the library), the new shared "
"library is already in place. In the past, this was achieved by creating "
"the library in the temporary packaging directory before creating the "
"symlink. Unfortunately, this was not always effective, since the building"
" of the tar file in the ``.deb`` depended on the behavior of the "
"underlying file system. Some file systems (such as reiserfs) reorder the "
"files so that the order of creation is forgotten. Since version 1.7.0, "
"``dpkg`` reorders the files itself as necessary when building a package. "
"Thus it is no longer important to concern oneself with the order of file "
"creation."
msgstr ""

#: ../../ch-sharedlibs.rst:166
msgid "``ldconfig``"
msgstr ""

#: ../../ch-sharedlibs.rst:168
msgid ""
"Any package installing shared libraries in one of the default library "
"directories of the dynamic linker (which are currently ``/usr/lib`` and "
"``/lib``) or a directory that is listed in ``/etc/ld.so.conf`` [#]_ must "
"use ``ldconfig`` to update the shared library system."
msgstr ""

#: ../../ch-sharedlibs.rst:173
msgid ""
"Any such package must have the line ``activate-noawait ldconfig`` in its "
"``triggers`` control file (i.e. ``DEBIAN/triggers``)."
msgstr ""

#: ../../ch-sharedlibs.rst:176
msgid ""
"These are currently ``/usr/local/lib`` plus directories under ``/lib`` "
"and ``/usr/lib`` matching the multiarch triplet for the system "
"architecture."
msgstr ""

#: ../../ch-sharedlibs.rst:183
msgid "Shared library support files"
msgstr ""

#: ../../ch-sharedlibs.rst:185
msgid ""
"If your package contains files whose names do not change with each change"
" in the library shared object version, you must not put them in the "
"shared library package. Otherwise, several versions of the shared library"
" cannot be installed at the same time without filename clashes, making "
"upgrades and transitions unnecessarily difficult."
msgstr ""

#: ../../ch-sharedlibs.rst:191
msgid ""
"It is recommended that supporting files and run-time support programs "
"that do not need to be invoked manually by users, but are nevertheless "
"required for the package to function, be placed (if they are binary) in a"
" subdirectory of ``/usr/lib``, preferably under ``/usr/lib/``\\ package-"
"name. If the program or file is architecture independent, the "
"recommendation is for it to be placed in a subdirectory of ``/usr/share``"
" instead, preferably under ``/usr/share/``\\ package-name. Following the "
"package-name naming convention ensures that the file names change when "
"the shared object version changes."
msgstr ""

#: ../../ch-sharedlibs.rst:202
msgid ""
"Run-time support programs that use the shared library but are not "
"required for the library to function or files used by the shared library "
"that can be used by any version of the shared library package should "
"instead be put in a separate package. This package might typically be "
"named libraryname-tools; note the absence of the soversion in the package"
" name."
msgstr ""

#: ../../ch-sharedlibs.rst:209
msgid ""
"Files and support programs only useful when compiling software against "
"the library should be included in the development package for the "
"library.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:213
msgid ""
"For example, a ``package-name-config`` script or pkg-config configuration"
" files."
msgstr ""

#: ../../ch-sharedlibs.rst:219
msgid "Static libraries"
msgstr ""

#: ../../ch-sharedlibs.rst:221
msgid ""
"The static library (``libraryname.a``) is usually provided in addition to"
" the shared version. It is placed into the development package (see "
"below)."
msgstr ""

#: ../../ch-sharedlibs.rst:225
msgid ""
"In some cases, it is acceptable for a library to be available in static "
"form only; these cases include:"
msgstr ""

#: ../../ch-sharedlibs.rst:228
msgid ""
"libraries for languages whose shared library support is immature or "
"unstable"
msgstr ""

#: ../../ch-sharedlibs.rst:231
msgid ""
"libraries whose interfaces are in flux or under development (commonly the"
" case when the library's major version number is zero, or where the ABI "
"breaks across patchlevels)"
msgstr ""

#: ../../ch-sharedlibs.rst:235
msgid ""
"libraries which are explicitly intended to be available only in static "
"form by their upstream author(s)"
msgstr ""

#: ../../ch-sharedlibs.rst:241
msgid "Development files"
msgstr ""

#: ../../ch-sharedlibs.rst:243
msgid ""
"If there are development files associated with a shared library, the "
"source package needs to generate a binary development package named "
"libraryname-dev, or if you need to support multiple development versions "
"at a time, librarynameapiversion-dev. Installing the development package "
"must result in installation of all the development files necessary for "
"compiling programs against that shared library.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:250
msgid ""
"In case several development versions of a library exist, you may need to "
"use ``dpkg``'s Conflicts mechanism (see :ref:`s-conflicts`) to ensure "
"that the user only installs one development version at a time (as "
"different development versions are likely to have the same header files "
"in them, which would cause a filename clash if both were unpacked)."
msgstr ""

#: ../../ch-sharedlibs.rst:256
msgid ""
"The development package should contain a symlink for the associated "
"shared library without a version number. For example, the libgdbm-dev "
"package should include a symlink from ``/usr/lib/libgdbm.so`` to "
"``libgdbm.so.3.0.0``. This symlink is needed by the linker (``ld``) when "
"compiling packages, as it will only look for ``libgdbm.so`` when "
"compiling dynamically."
msgstr ""

#: ../../ch-sharedlibs.rst:263
msgid ""
"If the package provides Ada Library Information (``*.ali``) files for use"
" with GNAT, these files must be installed read-only (mode 0444) so that "
"GNAT will not attempt to recompile them. This overrides the normal file "
"mode requirements given in :ref:`s-permissions-owners`."
msgstr ""

#: ../../ch-sharedlibs.rst:268
msgid ""
"This wording allows the development files to be split into several "
"packages, such as a separate architecture-independent libraryname-"
"headers, provided that the development package depends on all the "
"required additional packages."
msgstr ""

#: ../../ch-sharedlibs.rst:276
msgid "Dependencies between the packages of the same library"
msgstr ""

#: ../../ch-sharedlibs.rst:278
msgid ""
"Typically the development version should have an exact version dependency"
" on the runtime library, to make sure that compilation and linking "
"happens correctly. The ``${binary:Version}`` substitution variable can be"
" useful for this purpose.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:283
msgid ""
"Previously, ``${Source-Version}`` was used, but its name was confusing "
"and it has been deprecated since dpkg 1.13.19."
msgstr ""

#: ../../ch-sharedlibs.rst:289
msgid "Dependencies between the library and other packages"
msgstr ""

#: ../../ch-sharedlibs.rst:291
msgid ""
"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. 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 "
"``symbols`` file or a ``shlibs`` file. These provide information on the "
"package dependencies required to ensure the presence of interfaces "
"provided by this library. Any package with binaries or libraries linking "
"to a shared library must use these files to determine the required "
"dependencies when it is built. Other packages which use a shared library "
"(for example using ``dlopen()``) should compute appropriate dependencies "
"using these files at build time as well."
msgstr ""

#: ../../ch-sharedlibs.rst:309
msgid ""
"The two mechanisms differ in the degree of detail that they provide. A "
"``symbols`` file documents, for each symbol exported by a library, the "
"minimal version of the package any binary using this symbol will need. "
"This is typically the version of the package in which the symbol was "
"introduced. This information permits detailed analysis of the symbols "
"used by a particular package and construction of an accurate dependency, "
"but it requires the package maintainer to track more information about "
"the shared library."
msgstr ""

#: ../../ch-sharedlibs.rst:318
msgid ""
"A ``shlibs`` file, in contrast, only documents the last time the library "
"ABI changed in any way. It only provides information about the library as"
" a whole, not individual symbols. When a package is built using a shared "
"library with only a ``shlibs`` file, the generated dependency will "
"require a version of the shared library equal to or newer than the "
"version of the last ABI change. This generates unnecessarily restrictive "
"dependencies compared to ``symbols`` files if none of the symbols used by"
" the package have changed. This, in turn, could make upgrades needlessly "
"complex and unnecessarily restrict use of the package on systems with "
"older versions of the shared libraries."
msgstr ""

#: ../../ch-sharedlibs.rst:329
msgid ""
"``shlibs`` files also only support a limited range of library SONAMEs, "
"making it difficult to use ``shlibs`` files in some unusual corner cases."
"  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:333
msgid ""
"``symbols`` files are therefore recommended for most shared library "
"packages since they provide more accurate dependencies. For most C "
"libraries, the additional detail required by ``symbols`` files is not too"
" difficult to maintain. However, maintaining exhaustive symbols "
"information for a C++ library can be quite onerous, so ``shlibs`` files "
"may be more appropriate for most C++ libraries. Libraries with a "
"corresponding udeb must also provide a ``shlibs`` file, since the udeb "
"infrastructure does not use ``symbols`` files."
msgstr ""

#: ../../ch-sharedlibs.rst:342
msgid ""
"A ``shlibs`` file represents an SONAME as a library name and version "
"number, such as ``libfoo VERSION``, instead of recording the actual "
"SONAME. If the SONAME doesn't match one of the two expected formats "
"(``libfoo-VERSION.so`` or ``libfoo.so.VERSION``), it cannot be "
"represented."
msgstr ""

#: ../../ch-sharedlibs.rst:351
msgid "Generating dependencies on shared libraries"
msgstr ""

#: ../../ch-sharedlibs.rst:353
msgid ""
"When a package that contains any shared libraries or compiled binaries is"
" built, it must run ``dpkg-shlibdeps`` on each shared library and "
"compiled binary to determine the libraries used and hence the "
"dependencies needed by the package. [#]_ To do this, put a call to "
"``dpkg-shlibdeps`` into your ``debian/rules`` file in the source package."
" List all of the compiled binaries, libraries, or loadable modules in "
"your package. [#]_ ``dpkg-shlibdeps`` will use the ``symbols`` or "
"``shlibs`` files installed by the shared libraries to generate dependency"
" information. The package must then provide a substitution variable into "
"which the discovered dependency information can be placed."
msgstr ""

#: ../../ch-sharedlibs.rst:364
msgid ""
"If you are creating a udeb for use in the Debian Installer, you will need"
" to specify that ``dpkg-shlibdeps`` should use the dependency line of "
"type ``udeb`` by adding the ``-tudeb`` option.  [#]_ If there is no "
"dependency line of type ``udeb`` in the ``shlibs`` file, ``dpkg-"
"shlibdeps`` will fall back to the regular dependency line."
msgstr ""

#: ../../ch-sharedlibs.rst:370
msgid ""
"``dpkg-shlibdeps`` puts the dependency information into the "
"``debian/substvars`` file by default, which is then used by ``dpkg-"
"gencontrol``. You will need to place a ``${shlibs:Depends}`` variable in "
"the ``Depends`` field in the control file of every binary package built "
"by this source package that contains compiled binaries, libraries, or "
"loadable modules. If you have multiple binary packages, you will need to "
"call ``dpkg-shlibdeps`` on each one which contains compiled libraries or "
"binaries. For example, you could use the ``-T`` option to the ``dpkg`` "
"utilities to specify a different ``substvars`` file for each binary "
"package.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:381
msgid "For more details on ``dpkg-shlibdeps``, see its manual page."
msgstr ""

#: ../../ch-sharedlibs.rst:383
msgid ""
"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. ``dpkg-shlibdeps`` "
"will handle this logic automatically, but package maintainers need to be "
"aware of this distinction between directly and indirectly using a library"
" if they have to override its results for some reason.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:396
msgid ""
"``dpkg-shlibdeps`` will use a program like ``objdump`` or ``readelf`` to "
"find the libraries and the symbols in those libraries directly needed by "
"the binaries or shared libraries in the package."
msgstr ""

#: ../../ch-sharedlibs.rst:401
msgid ""
"The easiest way to call ``dpkg-shlibdeps`` correctly is to use a package "
"helper framework such as debhelper. If you are using debhelper, the "
"``dh_shlibdeps`` program will do this work for you. It will also "
"correctly handle multi-binary packages."
msgstr ""

#: ../../ch-sharedlibs.rst:406
msgid ""
"``dh_shlibdeps`` from the ``debhelper`` suite will automatically add this"
" option if it knows it is processing a udeb."
msgstr ""

#: ../../ch-sharedlibs.rst:409
msgid ""
"Again, ``dh_shlibdeps`` and ``dh_gencontrol`` will handle everything "
"except the addition of the variable to the control file for you if you're"
" using debhelper, including generating separate ``substvars`` files for "
"each binary package and calling ``dpkg-gencontrol`` with the appropriate "
"flags."
msgstr ""

#: ../../ch-sharedlibs.rst:415
msgid ""
"A good example of where this helps is the following: We could update "
"``libimlib`` with a new version that supports a new revision of a "
"graphics format called dgf (but retaining the same major version number) "
"and depends on a new library package libdgf4 instead of the older "
"libdgf3. If we used ``ldd`` to add dependencies for every library "
"directly or indirectly linked with a binary, every package that uses "
"``libimlib`` would need to be recompiled so it would also depend on "
"libdgf4 in order to retire the older libdgf3 package. Since dependencies "
"are only added based on ELF ``NEEDED`` attribute, packages using "
"``libimlib`` can rely on ``libimlib`` itself having the dependency on an "
"appropriate version of ``libdgf`` and do not need rebuilding."
msgstr ""

#: ../../ch-sharedlibs.rst:431
msgid "Shared library ABI changes"
msgstr ""

#: ../../ch-sharedlibs.rst:433
msgid ""
"Maintaining a shared library package using either ``symbols`` or "
"``shlibs`` files requires being aware of the exposed ABI of the shared "
"library and any changes to it. Both ``symbols`` and ``shlibs`` files "
"record every change to the ABI of the shared library; ``symbols`` files "
"do so per public symbol, whereas ``shlibs`` files record only the last "
"change for the entire library."
msgstr ""

#: ../../ch-sharedlibs.rst:440
msgid ""
"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.  [#]_ Adding new symbols to the shared library is a "
"backward-compatible change. Removing symbols from the shared library is "
"not. Changing the behavior of a symbol may or may not be backward-"
"compatible depending on the change; for example, changing a function to "
"accept a new enum constant not previously used by the library is "
"generally backward-compatible, but changing the members of a struct that "
"is passed into library functions is generally not unless the library "
"takes special precautions to accept old versions of the data structure."
msgstr ""

#: ../../ch-sharedlibs.rst:454
msgid ""
"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 :ref:`s-sharedlibs-runtime`. "
"The remainder of this section will deal with backward-compatible changes."
msgstr ""

#: ../../ch-sharedlibs.rst:461
msgid ""
"Backward-compatible changes require either updating or recording the "
"minimal-version for that symbol in ``symbols`` files or updating the "
"version in the dependencies in ``shlibs`` files. For more information on "
"how to do this in the two formats, see :ref:`s-symbols` and "
":ref:`s-shlibs`. Below are general rules that apply to both files."
msgstr ""

#: ../../ch-sharedlibs.rst:467
msgid ""
"The easy case is when a public symbol is added. Simply add the version at"
" which the symbol was introduced (for ``symbols`` files) or update the "
"dependency version (for ``shlibs``) files. But special care should be "
"taken to update dependency versions when the behavior of a public symbol "
"changes. This is easy to neglect, since there is no automated method of "
"determining such changes, but failing to update versions in this case "
"could result in binary packages with too-weak dependencies that will fail"
" at runtime, possibly in ways that can cause security vulnerabilities. If"
" the package maintainer believes that a symbol behavior change could have"
" occurred but isn't sure, it's safer to update the version rather than "
"leave it unmodified. This may result in unnecessarily strict "
"dependencies, but it ensures that packages whose dependencies are "
"satisfied will work properly."
msgstr ""

#: ../../ch-sharedlibs.rst:481
msgid ""
"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::"
msgstr ""

#: ../../ch-sharedlibs.rst:488
msgid ""
"If a new operation, ``OP_BAZ``, is added, the minimal-version of "
"``library_do_operation`` (for ``symbols`` files) or the version in the "
"dependency for the shared library (for ``shlibs`` files) must be "
"increased to the version at which ``OP_BAZ`` was introduced. Otherwise, a"
" binary built against the new version of the library (having detected at "
"compile-time that the library supports ``OP_BAZ``) may be installed with "
"a shared library that doesn't support ``OP_BAZ`` and will fail at runtime"
" when it tries to pass ``OP_BAZ`` into this function."
msgstr ""

#: ../../ch-sharedlibs.rst:497
msgid ""
"Dependency versions in either ``symbols`` or ``shlibs`` files normally "
"should not contain the Debian revision of the package, since the library "
"behavior is normally fixed for a particular upstream version and any "
"Debian packaging of that upstream version will have the same behavior. In"
" the rare case that the library behavior was changed in a particular "
"Debian revision, appending ``~`` to the end of the version that includes "
"the Debian revision is recommended, since this allows backports of the "
"shared library package using the normal backport versioning convention to"
" satisfy the dependency."
msgstr ""

#: ../../ch-sharedlibs.rst:507
msgid ""
"An example of an \"unreasonable\" program is one that uses library "
"interfaces that are documented as internal and unsupported. If the only "
"programs or libraries affected by a change are \"unreasonable\" ones, "
"other techniques, such as declaring ``Breaks`` relationships with "
"affected packages or treating their usage of the library as bugs in those"
" packages, may be appropriate instead of changing the SONAME.  However, "
"the default approach is to change the SONAME for any change to the ABI "
"that could break a program."
msgstr ""

#: ../../ch-sharedlibs.rst:519
msgid "The ``symbols`` system"
msgstr ""

#: ../../ch-sharedlibs.rst:521
msgid ""
"In the following sections, we will first describe where the various "
"``symbols`` files are to be found, then the ``symbols`` file format, and "
"finally how to create ``symbols`` files if your package contains a shared"
" library."
msgstr ""

#: ../../ch-sharedlibs.rst:529
msgid "The ``symbols`` files present on the system"
msgstr ""

#: ../../ch-sharedlibs.rst:531
msgid ""
"``symbols`` files for a shared library are normally provided by the "
"shared library package as a control file, but there are several override "
"paths that are checked first in case that information is wrong or "
"missing. The following list gives them in the order in which they are "
"read by ``dpkg-shlibdeps``. The first one that contains the required "
"information is used."
msgstr ""

#: ../../ch-sharedlibs.rst:550
msgid "``debian/*/DEBIAN/symbols``"
msgstr ""

#: ../../ch-sharedlibs.rst:539
msgid ""
"During the package build, if the package itself contains shared libraries"
" with ``symbols`` files, they will be generated in these staging "
"directories by ``dpkg-gensymbols`` (see `Providing a symbols file <#s"
"-providing-symbols>`__). ``symbols`` files found in the build tree take "
"precedence over ``symbols`` files from other binary packages."
msgstr ""

#: ../../ch-sharedlibs.rst:546
msgid ""
"These files must exist before ``dpkg-shlibdeps`` is run or the "
"dependencies of binaries and libraries from a source package on other "
"libraries from that same source package will not be correct. In practice,"
" this means that ``dpkg-gensymbols`` must be run before ``dpkg-"
"shlibdeps`` during the package build.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:555
msgid ""
"``/etc/dpkg/symbols/package.symbols.arch`` and "
"``/etc/dpkg/symbols/package.symbols``"
msgstr ""

#: ../../ch-sharedlibs.rst:553
msgid ""
"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."
msgstr ""

#: ../../ch-sharedlibs.rst:561
msgid "``symbols`` control files for packages installed on the system"
msgstr ""

#: ../../ch-sharedlibs.rst:558
msgid ""
"The ``symbols`` control files for all the packages currently installed on"
" the system are searched last. This will be the most common source of "
"shared library dependency information. These files can be read with "
"``dpkg-query --control-show package symbols``."
msgstr ""

#: ../../ch-sharedlibs.rst:563
msgid ""
"Be aware that if a ``debian/shlibs.local`` exists in the source package, "
"it will override any ``symbols`` files. This is the only case where a "
"``shlibs`` is used despite ``symbols`` files being present. See :ref:`s"
"-shlibs-paths` and :ref:`s-sharedlibs-shlibdeps` for more information."
msgstr ""

#: ../../ch-sharedlibs.rst:569
msgid ""
"An example may clarify. Suppose the source package ``foo`` generates two "
"binary packages, ``libfoo2`` and ``foo-runtime``. When building the "
"binary packages, the contents of the packages are staged in the "
"directories ``debian/libfoo2`` and ``debian/foo-runtime`` respectively. "
"(``debian/tmp`` could be used instead of one of these.)  Since "
"``libfoo2`` provides the ``libfoo`` shared library, it will contain a "
"``symbols`` file, which will be installed in "
"``debian/libfoo2/DEBIAN/symbols``, eventually to be included as a control"
" file in that package. When ``dpkg-shlibdeps`` is run on the executable "
"``debian/foo-runtime/usr/bin/foo-prog``, it will examine the "
"``debian/libfoo2/DEBIAN/symbols`` file to determine whether ``foo-"
"prog``'s library dependencies are satisfied by any of the libraries "
"provided by ``libfoo2``. Since those binaries were linked against the "
"just-built shared library as part of the build process, the ``symbols`` "
"file for the newly-built ``libfoo2`` must take precedence over a "
"``symbols`` file for any other ``libfoo2`` package already installed on "
"the system."
msgstr ""

#: ../../ch-sharedlibs.rst:591
msgid "The ``symbols`` File Format"
msgstr ""

#: ../../ch-sharedlibs.rst:593
msgid ""
"The following documents the format of the ``symbols`` control file as "
"included in binary packages. These files are built from template "
"``symbols`` files in the source package by ``dpkg-gensymbols``. The "
"template files support a richer syntax that allows ``dpkg-gensymbols`` to"
" do some of the tedious work involved in maintaining ``symbols`` files, "
"such as handling C++ symbols or optional symbols that may not exist on "
"particular architectures. When writing ``symbols`` files for a shared "
"library package, refer to :manpage:`dpkg-gensymbols(1)` for the richer "
"syntax."
msgstr ""

#: ../../ch-sharedlibs.rst:603
msgid ""
"A ``symbols`` may contain one or more entries, one for each shared "
"library contained in the package corresponding to that ``symbols``. Each "
"entry has the following format::"
msgstr ""

#: ../../ch-sharedlibs.rst:614
msgid ""
"To explain this format, we'll use the ``zlib1g`` package as an example, "
"which (at the time of writing) installs the shared library "
"``/usr/lib/libz.so.1.2.3.4``. Mandatory lines will be described first, "
"followed by optional lines."
msgstr ""

#: ../../ch-sharedlibs.rst:619
msgid ""
"``library-soname`` must contain exactly the value of the ELF ``SONAME`` "
"attribute of the shared library. In our example, this is ``libz.so.1``. "
"[#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:623
msgid ""
"``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."
msgstr ""

#: ../../ch-sharedlibs.rst:636
msgid ""
"In our example, the first line of the ``zlib1g`` ``symbols`` file would "
"be::"
msgstr ""

#: ../../ch-sharedlibs.rst:641
msgid ""
"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."
msgstr ""

#: ../../ch-sharedlibs.rst:653
msgid ""
"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 ``symbols`` file "
"therefore contains the lines::"
msgstr ""

#: ../../ch-sharedlibs.rst:663
msgid ""
"Packages using only ``compress`` would then get a dependency on ``zlib1g "
"(>= 1:1.1.4)``, but packages using ``compressBound`` would get a "
"dependency on ``zlib1g (>= 1:1.2.0)``."
msgstr ""

#: ../../ch-sharedlibs.rst:667
msgid ""
"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.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:675
msgid ""
"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 `library development package <#s"
"-sharedlibs-dev>`_ on which packages using this shared library declare a "
"build dependency. If this field is present, ``dpkg-shlibdeps`` uses it to"
" ensure that the resulting binary package dependency on the shared "
"library is at least as strict as the source package dependency on the "
"shared library development package.  [#]_ For our example, the ``zlib1g``"
" ``symbols`` file would contain::"
msgstr ""

#: ../../ch-sharedlibs.rst:687
msgid "Also see :manpage:`deb-symbols(5)`."
msgstr ""

#: ../../ch-sharedlibs.rst:689
msgid "This can be determined by using the command"
msgstr ""

#: ../../ch-sharedlibs.rst:695
msgid ""
"An example of where this may be needed is with a library that implements "
"the libGL interface. All GL implementations provide the same set of base "
"interfaces, and then may provide some additional interfaces only used by "
"programs that require that specific GL implementation. So, for example, "
"libgl1-mesa-glx may use the following ``symbols`` file::"
msgstr ""

#: ../../ch-sharedlibs.rst:708
msgid ""
"Binaries or shared libraries using only ``publicGlSymbol`` would depend "
"only on ``libgl1`` (which may be provided by multiple packages), but ones"
" using ``implementationSpecificSymbol`` would get a dependency on "
"``libgl1-mesa-glx (>= 6.5.2-7)``."
msgstr ""

#: ../../ch-sharedlibs.rst:713
msgid ""
"This field should normally not be necessary, since if the behavior of any"
" symbol has changed, the corresponding symbol minimal-version should have"
" been increased. But including it makes the ``symbols`` system more "
"robust by tightening the dependency in cases where the package using the "
"shared library specifically requires at least a particular version of the"
" shared library development package for some reason."
msgstr ""

#: ../../ch-sharedlibs.rst:724
msgid "Providing a ``symbols`` file"
msgstr ""

#: ../../ch-sharedlibs.rst:726
msgid ""
"If your package provides a shared library, you should arrange to include "
"a ``symbols`` control file following the format described above in that "
"package. You must include either a ``symbols`` control file or a "
"``shlibs`` control file."
msgstr ""

#: ../../ch-sharedlibs.rst:731
msgid ""
"Normally, this is done by creating a ``symbols`` in the source package "
"named ``debian/package.symbols`` or ``debian/symbols``, possibly with "
"``.arch`` appended if the symbols information varies by architecture. "
"This file may use the extended syntax documented in :manpage:`dpkg-"
"gensymbols(1)`.  Then, call ``dpkg-gensymbols`` as part of the package "
"build process. It will create ``symbols`` files in the package staging "
"area based on the binaries and libraries in the package staging area and "
"the ``symbols`` files in the source package. [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:740
msgid ""
"Packages that provide ``symbols`` files must keep them up-to-date to "
"ensure correct dependencies in packages that use the shared libraries. "
"This means updating the ``symbols`` file whenever a new public symbol is "
"added, changing the minimal-version field whenever a symbol changes "
"behavior or signature in a backward-compatible way (see :ref:`s"
"-sharedlibs-updates`), and changing the library-soname and main-"
"dependency-template, and probably all of the minimal-version fields, when"
" the library changes ``SONAME``. Removing a public symbol from the "
"``symbols`` file because it's no longer provided by the library normally "
"requires changing the ``SONAME`` of the library.  See :ref:`s-sharedlibs-"
"runtime` for more information on ``SONAME``\\ s."
msgstr ""

#: ../../ch-sharedlibs.rst:752
msgid ""
"If you are using ``debhelper``, ``dh_makeshlibs`` will take care of "
"calling either ``dpkg-gensymbols`` or generating a ``shlibs`` file as "
"appropriate."
msgstr ""

#: ../../ch-sharedlibs.rst:759
msgid "The ``shlibs`` system"
msgstr ""

#: ../../ch-sharedlibs.rst:761
msgid ""
"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``."
msgstr ""

#: ../../ch-sharedlibs.rst:768
msgid ""
"In the following sections, we will first describe where the various "
"``shlibs`` files are to be found, then how to use ``dpkg-shlibdeps``, and"
" finally the ``shlibs`` file format and how to create them."
msgstr ""

#: ../../ch-sharedlibs.rst:775
msgid "The ``shlibs`` files present on the system"
msgstr ""

#: ../../ch-sharedlibs.rst:777
msgid ""
"There are several places where ``shlibs`` files are found. The following "
"list gives them in the order in which they are read by ``dpkg-"
"shlibdeps``. (The first one which gives the required information is "
"used.)"
msgstr ""

#: ../../ch-sharedlibs.rst:788
msgid "``debian/shlibs.local``"
msgstr ""

#: ../../ch-sharedlibs.rst:783
msgid ""
"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 ``shlibs`` file for a library "
"cannot be used. This file overrides information obtained from any other "
"source."
msgstr ""

#: ../../ch-sharedlibs.rst:792
msgid "``/etc/dpkg/shlibs.override``"
msgstr ""

#: ../../ch-sharedlibs.rst:791
msgid ""
"This lists global overrides. This list is normally empty. It is "
"maintained by the local system administrator."
msgstr ""

#: ../../ch-sharedlibs.rst:798
msgid "``DEBIAN/shlibs`` files in the \"build directory\""
msgstr ""

#: ../../ch-sharedlibs.rst:795
msgid ""
"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."
msgstr ""

#: ../../ch-sharedlibs.rst:803
msgid "``shlibs`` control files for packages installed on the system"
msgstr ""

#: ../../ch-sharedlibs.rst:801
msgid ""
"The ``shlibs`` control files for all the packages currently installed on "
"the system. These files can be read using ``dpkg-query --control-show "
"package shlibs``."
msgstr ""

#: ../../ch-sharedlibs.rst:809
msgid "``/etc/dpkg/shlibs.default``"
msgstr ""

#: ../../ch-sharedlibs.rst:806
msgid ""
"This file lists any shared libraries whose packages have failed to "
"provide correct ``shlibs`` files. It was used when the ``shlibs`` setup "
"was first introduced, but it is now normally empty. It is maintained by "
"the ``dpkg`` maintainer."
msgstr ""

#: ../../ch-sharedlibs.rst:811
msgid ""
"If a ``symbols`` file for a shared library package is available, ``dpkg-"
"shlibdeps`` will always use it in preference to a ``shlibs``, with the "
"exception of ``debian/shlibs.local``. The latter overrides any other "
"``shlibs`` or ``symbols`` files."
msgstr ""

#: ../../ch-sharedlibs.rst:819
msgid "The ``shlibs`` File Format"
msgstr ""

#: ../../ch-sharedlibs.rst:821
msgid ""
"Each ``shlibs`` file has the same format. Lines beginning with ``#`` are "
"considered to be comments and are ignored. Each line is of the form::"
msgstr ""

#: ../../ch-sharedlibs.rst:826
msgid ""
"We will explain this by reference to the example of the ``zlib1g`` "
"package, which (at the time of writing) installs the shared library "
"``/usr/lib/libz.so.1.2.3.4``."
msgstr ""

#: ../../ch-sharedlibs.rst:830
msgid ""
"``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."
msgstr ""

#: ../../ch-sharedlibs.rst:834
msgid ""
"``library-name`` is the name of the shared library, in this case "
"``libz``. (This must match the name part of the soname, see below.)"
msgstr ""

#: ../../ch-sharedlibs.rst:837
msgid ""
"``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 :ref:`s"
"-sharedlibs-runtime` for the details."
msgstr ""

#: ../../ch-sharedlibs.rst:842
msgid ""
"``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 :ref:`s-depsyntax` for details on the "
"syntax, and :ref:`s-sharedlibs-updates` for details on how to maintain "
"the dependency version constraint."
msgstr ""

#: ../../ch-sharedlibs.rst:849
msgid ""
"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::"
msgstr ""

#: ../../ch-sharedlibs.rst:856
msgid ""
"This version restriction must be new enough that any binary built against"
" the current version of the library will work with any version of the "
"shared library that satisfies that dependency."
msgstr ""

#: ../../ch-sharedlibs.rst:860
msgid ""
"As zlib1g also provides a udeb containing the shared library, there would"
" also be a second line::"
msgstr ""

#: ../../ch-sharedlibs.rst:868
msgid "Providing a ``shlibs`` file"
msgstr ""

#: ../../ch-sharedlibs.rst:870
msgid ""
"To provide a ``shlibs`` file for a shared library binary package, create "
"a ``shlibs`` file following the format described above and place it in "
"the ``DEBIAN`` directory for that package during the build. It will then "
"be included as a control file for that package.  [#]_"
msgstr ""

#: ../../ch-sharedlibs.rst:875
msgid ""
"Since ``dpkg-shlibdeps`` reads the ``DEBIAN/shlibs`` files in all of the "
"binary packages being built from this source package, all of the "
"``DEBIAN/shlibs`` files should be installed before ``dpkg-shlibdeps`` is "
"called on any of the binary packages."
msgstr ""

#: ../../ch-sharedlibs.rst:880
msgid ""
"This is what ``dh_makeshlibs`` in the debhelper suite does. If your "
"package also has a udeb that provides a shared library, ``dh_makeshlibs``"
" can automatically generate the ``udeb:`` lines if you specify the name "
"of the udeb with the ``--add-udeb`` option."
msgstr ""

#~ msgid ""
#~ "The run-time shared library must "
#~ "be placed in a package whose name"
#~ " changes whenever the ``SONAME`` of "
#~ "the shared library changes. This allows"
#~ " several versions of the shared "
#~ "library to be installed at the "
#~ "same time, allowing installation of the"
#~ " new version of the shared library"
#~ " without immediately breaking binaries that"
#~ " depend on the old version. Normally,"
#~ " the run-time shared library and "
#~ "its ``SONAME`` symlink should be placed"
#~ " in a package named libraryname\\ "
#~ "*soversion*, where *soversion* is the "
#~ "version number in the ``SONAME`` of "
#~ "the shared library.  Alternatively, if "
#~ "it would be confusing to directly "
#~ "append *soversion* to libraryname (if, "
#~ "for example, libraryname itself ends in"
#~ " a number), you should use "
#~ "libraryname-\\ *soversion* instead. [#]_"
#~ msgstr ""

#~ msgid ""
#~ "The following documents the format of"
#~ " the ``symbols`` control file as "
#~ "included in binary packages. These files"
#~ " are built from template ``symbols`` "
#~ "files in the source package by "
#~ "``dpkg-gensymbols``. The template files "
#~ "support a richer syntax that allows "
#~ "``dpkg-gensymbols`` to do some of "
#~ "the tedious work involved in maintaining"
#~ " ``symbols`` files, such as handling "
#~ "C++ symbols or optional symbols that "
#~ "may not exist on particular "
#~ "architectures. When writing ``symbols`` files"
#~ " for a shared library package, refer"
#~ " to dpkg-gensymbols(1) for the richer"
#~ " syntax."
#~ msgstr ""

#~ msgid "Also see ``deb-symbols(5)``."
#~ msgstr ""

#~ msgid ""
#~ "Normally, this is done by creating "
#~ "a ``symbols`` in the source package "
#~ "named ``debian/package.symbols`` or "
#~ "``debian/symbols``, possibly with ``.arch`` "
#~ "appended if the symbols information "
#~ "varies by architecture. This file may"
#~ " use the extended syntax documented "
#~ "in dpkg-gensymbols(1). Then, call "
#~ "``dpkg-gensymbols`` as part of the "
#~ "package build process. It will create"
#~ " ``symbols`` files in the package "
#~ "staging area based on the binaries "
#~ "and libraries in the package staging "
#~ "area and the ``symbols`` files in "
#~ "the source package. [#]_"
#~ msgstr ""

#~ msgid ""
#~ "Every time the shared library ABI "
#~ "changes in a way that may break"
#~ " binaries linked against older versions "
#~ "of the shared library, the ``SONAME``"
#~ " of the library and the corresponding"
#~ " name for the binary package "
#~ "containing the runtime shared library "
#~ "should change. Normally, this means the"
#~ " ``SONAME`` should change any time an"
#~ " interface is removed from the shared"
#~ " library or the signature of an "
#~ "interface (the number of parameters or"
#~ " the types of parameters that it "
#~ "takes, for example) is changed. This "
#~ "practice is vital to allowing clean "
#~ "upgrades from older versions of the "
#~ "package and clean transitions between "
#~ "the old ABI and new ABI without"
#~ " having to upgrade every affected "
#~ "package simultaneously."
#~ msgstr ""

#~ msgid ""
#~ "A ``shlibs`` file, in contrast, only "
#~ "documents the last time the library "
#~ "ABI changed in any way. It only"
#~ " provides information about the library "
#~ "as a whole, not individual symbols. "
#~ "When a package is built using a"
#~ " shared library with only a "
#~ "``shlibs`` file, the generated dependency "
#~ "will require a version of the "
#~ "shared library equal to or newer "
#~ "than the version of the last ABI"
#~ " change. This generates unnecessarily "
#~ "restrictive dependencies compared to "
#~ "``symbols`` files if none of the "
#~ "symbols used by the package have "
#~ "changed. This, in turn, may make "
#~ "upgrades needlessly complex and unnecessarily"
#~ " restrict use of the package on "
#~ "systems with older versions of the "
#~ "shared libraries."
#~ msgstr ""

#~ msgid ""
#~ "The easy case is when a public "
#~ "symbol is added. Simply add the "
#~ "version at which the symbol was "
#~ "introduced (for ``symbols`` files) or "
#~ "update the dependency version (for "
#~ "``shlibs``) files. But special care "
#~ "should be taken to update dependency "
#~ "versions when the behavior of a "
#~ "public symbol changes. This is easy "
#~ "to neglect, since there is no "
#~ "automated method of determining such "
#~ "changes, but failing to update versions"
#~ " in this case may result in "
#~ "binary packages with too-weak "
#~ "dependencies that will fail at runtime,"
#~ " possibly in ways that can cause "
#~ "security vulnerabilities. If the package "
#~ "maintainer believes that a symbol "
#~ "behavior change may have occurred but"
#~ " isn't sure, it's safer to update "
#~ "the version rather than leave it "
#~ "unmodified. This may result in "
#~ "unnecessarily strict dependencies, but it "
#~ "ensures that packages whose dependencies "
#~ "are satisfied will work properly."
#~ msgstr ""

