Contributing
------------
APT is maintained in git, the official repository being located at
-`git://anonscm.debian.org/apt/apt.git` ([webgit](http://anonscm.debian.org/gitweb/?p=apt/apt.git)),
+`git://anonscm.debian.org/apt/apt.git` ([webgit](https://anonscm.debian.org/git/apt/apt.git)),
but also available at other locations like [GitHub](https://github.com/Debian/apt).
The default branch is `master`, other branches targeted at different
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](http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=blob;f=doc/style.txt) for more on this).
+namely 3 spaces with 8 space tab (see [doc/style.txt](https://anonscm.debian.org/git/apt/apt.git/tree/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
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 runtime via an `APT_CONFIG`
+configuration file.
+
### Integration tests
-There is a extensive integration testsuite available which can be run via:
+There is an extensive integration testsuite available which can be run via:
$ ./test/integration/run-tests
-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](https://travis-ci.org/)
-as well as via autopkgtests e.g. on [Debian Continuous Integration](http://ci.debian.net/?q=apt#package/apt).
+Each test can also be run individually as well. The tests are very noisy by
+default, especially so while running all of them it might be beneficial to
+enabling 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](https://travis-ci.org/) and
+[Shippable](https://shippable.com/) as well as via autopkgtests e.g. on
+[Debian Continuous Integration](https://ci.debian.net/packages/a/apt/).
A testcase here is a shellscript 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
### Unit tests
-These tests are gtest-dev based, reside in `./test/libapt` and can be run with `make test`.
-They are executed at package build-time, but not by `make`.
+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`.
Debugging
---------
useful options, but is in no way exhaustive.
Note that you should *NEVER* use these settings as root to avoid accidents.
-Similation mode (`-s`) is usually sufficient to help you run apt as a non-root user.
+Simulation mode (`-s`) is usually sufficient to help you run apt as a non-root user.
### Using different state files
projects / apt.git / blobdiff