The entire concept of PendingError() is flawed :/.

[apt.git] / README.md

diff --git a/README.md b/README.md
index 1c10197130515421de5f2bd1e3fdcba25e49570f..5c8fb1ad0364e588e4c555b9c0f5e0cfe2996abd 100644 (file)
--- a/README.md
+++ b/README.md
@@ -35,7 +35,7 @@ Our bugtracker as well as a general overview can be found at the [Debian Tracker
 Contributing
 ------------
 APT is maintained in git, the official repository being located at
 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
 but also available at other locations like [GitHub](https://github.com/Debian/apt).
 
 The default branch is `master`, other branches targeted at different


@@ -62,7 +62,7 @@ You can also use the Ninja generator of cmake, to do that pass
 to the cmake invocation, and then use ninja instead of make.
 
 The source code uses in most parts a relatively uncommon indent convention,
 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
 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


@@ -98,15 +98,27 @@ Testing
 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.
 
 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
 
 ### 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
 
 
        $ ./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
 
 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


@@ -115,8 +127,10 @@ itself as well as in conjunction with dpkg and other tools while working with pa
 
 ### Unit tests
 
 
 ### 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
 ---------
 
 Debugging
 ---------


@@ -127,7 +141,7 @@ in certain areas. The following describes some common scenarios and generally
 useful options, but is in no way exhaustive.
 
 Note that you should *NEVER* use these settings as root to avoid accidents.
 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
 
 
 ### Using different state files