代码拉取完成，页面将自动刷新
apt is the main command-line package manager for Debian and its derivatives. It provides command-line tools for searching and managing as well as querying information about packages as well as low-level access to all features provided by the libapt-pkg and libapt-inst libraries which higher-level package managers can depend upon.
Included tools are:
The libraries libapt-pkg and libapt-inst are also maintained as part of this project, alongside various additional binaries like the acquire methods used by them. Bindings for Python (python-apt) and Perl (libapt-pkg-perl) are available as separated projects.
Discussion happens mostly on the mailing list (archive) and on IRC. Our bug tracker as well as a general overview can be found at the Debian Tracker page.
APT is maintained in git, the official repository being located at https://salsa.debian.org/apt-team/apt, but also available at other locations like GitHub.
The default branch is main, other branches targeted at different
derivatives and releases being used as needed. Various topic branches in
different stages of completion might be branched of from those, which you
are encouraged to do as well.
APT uses CMake. To start building, you need to run
cmake <path to source directory>
from a build directory. For example, if you want to build in the source tree, run:
cmake .
Then you can use make as you normally would (pass -j <count> to perform <count>
jobs in parallel).
You can also use the Ninja generator of CMake, to do that pass -G Ninja to the cmake invocation, and then use ninja instead of make.
The source code uses in most parts a relatively uncommon indent convention,
namely 3 spaces with 8 space tab (see doc/style.txt for more on this).
Adhering to it avoids unnecessary code-churn destroying history (aka: git blame)
and you are therefore encouraged to write patches in this style.
Your editor can surely help you with this, for vim the settings would be
setlocal shiftwidth=3 noexpandtab tabstop=8
(the latter two are the default configuration and could therefore be omitted).
While we welcome contributions here, we highly encourage you to contact the Debian Internationalization (i18n) team. Various language teams have formed which can help you create, maintain and improve a translation, while we could only do a basic syntax check of the file format…
Further more, translating APT is split into two independent parts: The program translation, meaning the messages printed by the tools, as well as the manual pages and other documentation shipped with APT.
Software tools like APT, which are used by thousands of users every day, have a steady flow of incoming bug reports. Not all of them are really bugs in APT: It can be packaging bugs, like failing maintainer scripts, that a user reports against apt, because apt was the command they executed that led to this failure; or various wishlist items for new features. Given enough time the occasional duplicate enters the system as well. Our bug tracker is therefore full with open bug reports which are waiting for you! ;)
When you make changes and want to run them manually, you can just do so. CMake automatically inserts an rpath so the binaries find the correct libraries.
Note that you have to invoke CMake with the right install prefix set (e.g.
-DCMAKE_INSTALL_PREFIX=/usr) to have your build find and use the right files
by default or alternatively set the locations at run-time via an APT_CONFIG
configuration file.
There is an extensive integration test suite available which can be run via:
$ ./test/integration/run-tests
Each test can be run individually as well. The tests are very noisy by
default, especially so while running all of them; it might be beneficial to
enable quiet (-q) or very quiet (-qq) mode. The tests can also be run in
parallel via -j X where X is the number of jobs to run.
While these tests are not executed at package build-time as they require additional dependencies, the repository contains the configuration needed to run them on Travis CI and Shippable as well as via autopkgtests e.g. on Debian Continuous Integration.
A test case here is a shell script embedded in a framework creating an environment in which apt tools can be used naturally without root-rights to test every aspect of its behavior itself as well as in conjunction with dpkg and other tools while working with packages.
These tests are gtest-dev based, executed by ctest, reside in ./test/libapt
and can be run with make test. They are executed at package build-time, but
not by make. CTest by default does not show the output of tests, even if they
failed, so to see more details you can also run them with ctest --verbose.
APT does many things, so there is no central debug mode which could be activated. Instead, it uses various configuration options to activate debug output in certain areas. The following describes some common scenarios and generally useful options, but is in no way exhaustive.
Note that, to avoid accidents, you should NEVER use these settings as root.
Simulation mode (-s) is usually sufficient to help you run apt as a non-root user.
If a dependency solver bug is reported, but can't easily be reproduced by the
triager, it is beneficial to ask the reporter for the
/var/lib/dpkg/status file which includes the packages installed on the
system and in which version. Such a file can then be used via the option
dir::state::status. Beware of different architecture settings!
Bug reports usually include this information in the template. Assuming you
already have the Packages files for the architecture (see sources.list
manpage for the arch= option) you can change to a different architecture
with a configuration file like:
APT::Architecture "arch1";
#clear APT::Architectures;
APT:: Architectures { "arch1"; "arch2"; }
If a certain mirror state is needed, see if you can reproduce it with snapshot.debian.org.
Your sources.list file (dir::etc::sourcelist) has to correctly mention the repository,
but if it does, you can use different downloaded archive state files via dir::state::lists.
In case manually vs. automatically installed matters, you can ask the reporter for
the /var/lib/apt/extended_states file and use it with dir::state::extended_states.
APT works in its internal resolver in two stages: First all packages are visited
and marked for installation, keep back or removal. Option Debug::pkgDepCache::Marker
shows this. This also decides which packages are to be installed to satisfy dependencies,
which can be seen by Debug::pkgDepCache::AutoInstall. After this is done, we might
be in a situation in which two packages want to be installed, but only one of them can be.
It is the job of the pkgProblemResolver to decide which of two packages 'wins' and can
therefore decide what has to happen. You can see the contenders as well as their fight and
the resulting resolution with Debug::pkgProblemResolver.
Various binaries (called 'methods') are tasked with downloading files. The Acquire system
talks to them via simple text protocol. Depending on which side you want to see, either
Debug::pkgAcquire::Worker or Debug::Acquire::http (or similar) will show the messages.
The integration tests use a simple self-built web server (webserver) which also logs. If you find that
the http(s) methods do not behave like they should then try to implement this behavior in
webserver for simpler and more controlled testing.
Dependencies are solved, packages downloaded: Everything is ready for the installation!
The last step in the chain is often forgotten, but still very important:
Packages have to be installed in a particular order so that their dependencies are
satisfied, but at the same time you don't want to install very important and optional
packages at the same time if possible, so that a broken optional package does not
block the correct installation of very important packages. Which option to use depends on
if you are interested in the topology sorting (Debug::pkgOrderList), the dependency-aware
cycle and unconfigured prevention (Debug::pkgPackageManager) or the actual calls
to dpkg (Debug::pkgDpkgPm).
Many more things could and should be said about APT and its usage but are more targeted at developers of related programs or only of special interest.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。