同步操作将从 openKylin/apt 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
This document describes the communication protocol between APT and external dependency solvers. The protocol is called APT EDSP, for "APT External Dependency Solver Protocol".
In the following we use the term architecture qualified package name (or arch-qualified package names for short) to refer to package identifiers of the form "package:arch" where "package" is a package name and "arch" a dpkg architecture.
internal
.At each interaction with APT, a single solver is in use. When there is a total of 2 or more solvers, internals or externals, the user can choose which one to use.
Each solver is identified by an unique string, the solver
name. Solver names must be formed using only alphanumeric ASCII
characters, dashes, and underscores; solver names must start with a
lowercase ASCII letter. The special name internal
denotes APT's
internal solver, is reserved, and cannot be used by external solvers.
Each external solver is installed as a file under Dir::Bin::Solvers (see
below), which defaults to /usr/lib/apt/solvers
. We will assume in the
remainder of this section that such a default value is in effect.
The naming scheme is /usr/lib/apt/solvers/NAME
, where NAME
is the
name of the external solver.
Each file under /usr/lib/apt/solvers
corresponding to an external
solver must be executable.
No non-solver files must be installed under /usr/lib/apt/solvers
, so
that an index of available external solvers can be obtained by listing
the content of that directory.
Several APT options can be used to affect dependency solving in APT. An overview of them is given below. Please refer to proper APT configuration documentation for more, and more up to date, information.
APT::Solver: the name of the solver to be used for
dependency solving. Defaults to internal
Dir::Bin::Solvers: absolute path of the directory where to look for
external solvers. Defaults to /usr/lib/apt/solvers
.
APT::Solver::Strict-Pinning: whether pinning must be strictly
respected (as the internal solver does) or can be slightly deviated
from. Defaults to yes
.
APT::Solver::Preferences: user preference string used during dependency solving by the requested solver. Check the documentation of the solver you are using if and what is supported as a value here. Defaults to the empty string.
APT::Solver::RunAsUser: if APT itself is run as root it will
change to this user before executing the solver. Defaults to the value
of APT::Sandbox::User, which itself defaults to _apt
. Can be
disabled by set this option to root
.
The options Strict-Pinning and Preferences can also be set for
a specific solver only via APT::Solver::NAME::Strict-Pinning and
APT::Solver::NAME::Preferences respectively where NAME
is the name
of the external solver this option should apply to. These options if set
override the generic options; for simplicity the documentation will
refer only to the generic options.
When configured to use an external solver, APT will resort to it to decide which packages should be installed or removed.
The interaction happens in batch: APT will invoke the external solver passing the current status of installed and available packages, as well as the user request to alter the set of installed packages. The external solver will compute a new complete set of installed packages and gives APT a "diff" listing of which additional packages should be installed and of which currently installed packages should be removed. (Note: the order in which those actions have to be performed will be up to APT to decide.)
External solvers are invoked by executing them. Communications happens via the file descriptors: stdin (standard input) and stdout (standard output). stderr is not used by the EDSP protocol. Solvers can therefore use stderr to dump debugging information that could be inspected separately.
After invocation, the protocol passes through a sequence of phases:
A scenario is a text file encoded in a format very similar to the "Deb
822" format (AKA "the format used by Debian Packages
files"). A
scenario consists of two distinct parts: a request and a package
universe, occurring in that order. The request consists of a single
Deb 822 stanza, while the package universe consists of several such
stanzas. All stanzas occurring in a scenario are separated by an empty
line.
Within a dependency solving scenario, a request represents the action on installed packages requested by the user.
A request is a single Deb 822 stanza opened by a mandatory Request field and followed by a mixture of action, preference, and global configuration fields.
The value of the Request: field is a string describing the EDSP
protocol which will be used to communicate. At present, the string must
be EDSP 0.5
. Request fields are mainly used to identify the beginning
of a request stanza; their actual values are otherwise not used by the
EDSP protocol.
The following configuration fields are supported in request stanzas:
Architecture: (mandatory) The name of the native architecture on
the user machine (see also: dpkg --print-architecture
)
Architectures: (optional, defaults to the native architecture) A
space separated list of all architectures known to APT (this is
roughly equivalent to the union of dpkg --print-architecture
and
dpkg --print-foreign-architectures
)
The following action fields are supported in request stanzas:
Install: (optional, defaults to the empty string) A space
separated list of arch-qualified package names, with no version
attached, to install. This field denotes a list of packages that the
user wants to install, usually via an APT install
request.
Remove: (optional, defaults to the empty string) Same syntax of
Install. This field denotes a list of packages that the user wants to
remove, usually via APT remove
or purge
requests.
Upgrade-All: (optional, defaults to no
). Allowed values yes
,
no
. When set to yes
, an upgrade of all installed packages has been
requested, usually via an upgrade command like 'apt full-upgrade'.
Autoremove: (optional, defaults to no
). Allowed values: yes
,
no
. When set to yes
, a clean up of unused automatically installed
packages has been requested, usually via an APT autoremove
request.
Upgrade: (deprecated, optional, defaults to no
). Allowed values:
yes
, no
. When set to yes
, an upgrade of all installed packages
has been requested, usually via an APT upgrade
request. A value of
yes
is equivalent to the fields Upgrade-All
,
Forbid-New-Install
and Forbid-Remove
all set to yes
.
Dist-Upgrade: (deprecated, optional, defaults to no
). Allowed
values: yes
, no
. Same as Upgrade, but for APT dist-upgrade
requests. A value of yes
is equivalent to the field Upgrade-All
set to yes
and the fields Forbid-New-Install
and Forbid-Remove
set to no
.
The following preference fields are supported in request stanzas:
Strict-Pinning: (optional, defaults to yes
). Allowed values:
yes
, no
. When set to yes
, APT pinning is strict, in the sense
that the solver must not propose to install packages which are not APT
candidates (see the APT-Pin
and APT-Candidate
fields in the
package universe). When set to no
, the solver does only a best
effort attempt to install APT candidates. Usually, the value of this
field comes from the APT::Solver::Strict-Pinning
configuration
option.
*Forbid-New-Install: (optional, defaults to no
). Allowed values:
yes
, no
. When set to yes
the resolver is forbidden to install
new packages in its returned solution.
*Forbid-Remove: (optional, defaults to no
). Allowed values: yes
,
no
. When set to yes
the resolver is forbidden to remove currently
installed packages in its returned solution.
Solver: (optional, defaults to the empty string) a purely informational string specifying to which solver this request was send initially.
Preferences: (optional, defaults to the empty string)
a solver-specific optimization string, usually coming from the
APT::Solver::Preferences
configuration option.
A package universe is a list of Deb 822 stanzas, one per package, called package stanzas. Each package stanzas starts with a Package field. The following fields are supported in package stanzas:
All fields contained in the dpkg database, with the exception of
fields marked as "internal" (see the manpage dpkg-query (1)
). Among
those fields, the following are mandatory for all package stanzas:
Package, Version, Architecture.
It is recommended not to pass the Description field to external solvers or, alternatively, to trim it to the short description only.
Installed: (optional, defaults to no
). Allowed values: yes
,
no
. When set to yes
, the corresponding package is currently
installed.
Note: the Status field present in the dpkg database must not be passed to the external solver, as it's an internal dpkg field. Installed and other fields permit one to encode the most relevant aspects of Status in communications with solvers.
Hold: (optional, defaults to no
). Allowed values: yes
,
no
. When set to yes
, the corresponding package is marked as "on
hold" by dpkg.
APT-ID: (mandatory). Unique package identifier, according to APT.
APT-Pin: (mandatory). Must be an integer. Package pin value, according to APT policy.
APT-Candidate: (optional, defaults to no
). Allowed values:
yes
, no
. When set to yes
, the corresponding package is the APT
candidate for installation among all available packages with the same
name and architecture.
APT-Automatic: (optional, defaults to no
). Allowed values:
yes
, no
. When set to yes
, the corresponding package is marked by
APT as automatic installed. Note that automatic installed packages
should be removed by the solver only when the Autoremove action is
requested (see Request section).
APT-Release: (optional) The releases the package belongs to, according to
APT. The format of this field is multiline with one value per line and the
first line (the one containing the field name) empty. Each subsequent line
corresponds to one of the releases the package belongs to and looks like
this: o=Debian,a=unstable,n=sid,l=Debian,c=main
. That is, each release line
is a comma-separated list of "key=value" pairs, each of which denotes a
Release file entry (Origin, Label, Codename, etc.) in the format of
APT_PREFERENCES(5).
Source: (optional) The name of the source package the binary package this record is for was built from. This field does NOT include the version of the source package unlike the Source field in the dpkg database. The version is optionally available in the Source-Version: field.
An answer from the external solver to APT is either a solution or an error.
The following invariant on exit codes must hold true. When the external solver is able to find a solution, it will write the solution to standard output and then exit with an exit code of 0. When the external solver is unable to find a solution (and is aware of that), it will write an error to standard output and then exit with an exit code of 0. An exit code other than 0 will be interpreted as a solver crash with no meaningful error about dependency resolution to convey to the user.
A solution is a list of Deb 822 stanzas. Each of them could be an install stanza (telling APT to install a specific new package or to upgrade or downgrade a package to a specific version), a remove stanza (telling APT to remove one), or an autoremove stanza (telling APT about the future possibility of removing a package using the Autoremove action).
An install stanza starts with an Install field and supports the following fields:
Install: (mandatory). The value is a package identifier, referencing one of the package stanzas of the package universe via its APT-ID field.
All fields supported by package stanzas.
Remove stanzas are similar to install stanzas, but have Remove fields instead of Install fields.
Autoremove stanzas are similar to install stanzas, but have Autoremove fields instead of Install fields. Autoremove stanzas should be output so that APT can inform the user of which packages they can now autoremove, as a consequence of the executed action. However, this protocol makes no assumption on the fact that a subsequent invocation of an Autoremove action will actually remove the very same packages indicated by Autoremove stanzas in the former solution.
A package can't be installed in multiple versions at the same time, so for each package there can at most one version be selected either for installation or removal. This especially means that a solver is neither allowed to represent package upgrades as a remove of the installed version and the installation of another (the remove is implicit and must be omitted from the solution) nor is it supported to revert previous actions in the solution with later actions. APT is allowed to show warnings and might even misbehave in earlier versions if a solver is violating this assumption.
In terms of expressivity, install and remove stanzas can carry one
single field each, as APT-IDs are enough to pinpoint packages to be
installed/removed. Nonetheless, for protocol readability, it is
recommended that solvers either add unconditionally the fields Package,
Version, and Architecture to all install/remove stanzas or,
alternatively, that they support a --verbose
command line flag that
explicitly enables the output of those fields in solutions.
An error is a single Deb 822 stanza, starting the field Error. The following fields are supported in error stanzas:
Error: (mandatory). The value of this field is ignored, although it should be a unique error identifier, such as a UUID.
Message: (mandatory). The value of this field is a text string, meant to be read by humans, that explains the cause of the solver error. Message fields might be multi-line, like the Description field in the dpkg database. The first line conveys a short message, which can be explained in more details using subsequent lines.
During dependency solving, an external solver may send progress information to APT using progress stanzas. A progress stanza starts with the Progress field and might contain the following fields:
Progress: (mandatory). The value of this field is a date and time timestamp from the UTC timezone, in RFC 2822 format (see 'date -uR' as an example). The timestamp provides a time annotation for the progress report.
Percentage: (optional). An integer from 0 to 100, representing the completion of the dependency solving process, as declared by the solver.
Message: (optional). A textual message, meant to be read by the APT user, telling what is going on within the dependency solving (e.g. the current phase of dependency solving, as declared by the solver).
Potential future extensions to this protocol, listed in no specific order, include:
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。