From 1c79e19b67d031b2177424ae76a9757554fabed2 Mon Sep 17 00:00:00 2001 From: Niels Thykier Date: Fri, 11 May 2018 06:36:56 +0000 Subject: [PATCH] doc/short-intro: Use literal style for package names etc. Signed-off-by: Niels Thykier --- doc/short-intro-to-migrations.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/short-intro-to-migrations.rst b/doc/short-intro-to-migrations.rst index ff580bc..956a6c6 100644 --- a/doc/short-intro-to-migrations.rst +++ b/doc/short-intro-to-migrations.rst @@ -158,7 +158,7 @@ Confirming a migration ^^^^^^^^^^^^^^^^^^^^^^ To start with; if a migration is accepted and "committed" (i.e. it will not -be rolled back), britney will include in a line starting with `final:` like +be rolled back), britney will include in a line starting with ``final:`` like in this example:: Apparently successful @@ -170,11 +170,11 @@ in this example:: The above example is a regular migration run where 4 source removal migration items and one source migration item where accepted (those listed on the -`final:` line). The rest of the information are various statistical counters +``final:`` line). The rest of the information are various statistical counters which are useful for other purposes beyond the scope of this document. When debugging a migration for an item that passed the previous phase, if the -item appears on a `final:` line like that, then it is migrated. That is, the +item appears on a ``final:`` line like that, then it is migrated. That is, the problem is most likely that the britney run crashes later or the britney's output is not committed to the archive (for reasons outside britney's control). @@ -189,7 +189,7 @@ Debugging failed migration attempts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Start by confirming that the migration item was not accepted (as described -in the above section). If the migration item does not appear on a `final:` line, +in the above section). If the migration item does not appear on a ``final:`` line, then we need to debug the actual migration attempts. Migration attempts look something like this:: @@ -216,8 +216,8 @@ something like this:: [...] FAILED -This example has one succeeding migration (`-webdis`) and one failing -(`libaws`) plus finally a failed `easy`-hint with several packages. +This example has one succeeding migration (``-webdis``) and one failing +(``libaws``) plus finally a failed ``easy``-hint with several packages. Both of the two first are "single item" migrations (i.e. the attempt only includes a single item in isolation). However, Britney can do multi-item migrations (even outside hints). @@ -228,7 +228,7 @@ for debugging. When in doubt, it is *usually* easiest to look at the attempt with the least amount of new uninstallable packages. In the libaws example, a total of 4 binary packages become -uninstallable on the architecture `arm64`. Here is the output again +uninstallable on the architecture ``arm64``. Here is the output again with this information high lighted:: migration item(s) being attemped @@ -266,6 +266,6 @@ we are not actually sure whether this problem is architecture specific. For While this tells us what britney tried to migrate and what would break (become uninstallable) as a result, it is not very helpful at explaining *why* things break. If there are few broken packages, it is often a question of -looking for `Breaks`-relations or `Depends`-relations with upper bounds on +looking for ``Breaks``-relations or ``Depends``-relations with upper bounds on versions / on old packages being removed. Alternatively, there are also tools -like `dose-debcheck`, which attempts to analyse and explain problems like this. +like ``dose-debcheck``, which attempts to analyse and explain problems like this.