manuals: simplify references to classes

Now that .bbclass is removed from class section titles.
We can now have, for example, :ref:`ref-classes-insane`
instead of :ref:`insane <ref-classes-insane>`.

Then, when necessary, rework paragraphs so that they
have lines of even length, not exceeding 80 characters.

(From yocto-docs rev: e76190e3be78c1e483bec0469f1e437dbf8f3791)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Suggested-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 7 insertions, 7 deletions

diff --git a/documentation/migration-guides/migration-general.rst b/documentation/migration-guides/migration-general.rst
index c3b8a785db..1820f5cfd8 100644
--- a/documentation/migration-guides/migration-general.rst
+++ b/documentation/migration-guides/migration-general.rst
@@ -76,24 +76,24 @@ any new Yocto Project release.
 
 - *Checking Image / SDK Changes*:
 
-   The :ref:`buildhistory <ref-classes-buildhistory>` class can be used
+   The :ref:`ref-classes-buildhistory` class can be used
    if you wish to check the impact of changes to images / SDKs across
    the migration (e.g. added/removed packages, added/removed files, size
    changes etc.). To do this, follow these steps:
 
-   #. Enable :ref:`buildhistory <ref-classes-buildhistory>` before the migration
+   #. Enable :ref:`ref-classes-buildhistory` before the migration
 
    #. Run a pre-migration build
 
-   #. Capture the :ref:`buildhistory <ref-classes-buildhistory>` output (as
+   #. Capture the :ref:`ref-classes-buildhistory` output (as
       specified by :term:`BUILDHISTORY_DIR`) and ensure it is preserved for
       subsequent builds. How you would do this depends on how you are running
       your builds - if you are doing this all on one workstation in the same
       :term:`Build Directory` you may not need to do anything other than not
-      deleting the :ref:`buildhistory <ref-classes-buildhistory>` output
+      deleting the :ref:`ref-classes-buildhistory` output
       directory. For builds in a pipeline it may be more complicated.
 
-   #. Set a tag in the :ref:`buildhistory <ref-classes-buildhistory>` output (which is a git repository) before
+   #. Set a tag in the :ref:`ref-classes-buildhistory` output (which is a git repository) before
       migration, to make the commit from the pre-migration build easy to find
       as you may end up running multiple builds during the migration.
 
@@ -102,7 +102,7 @@ any new Yocto Project release.
    #. Run a build
 
    #. Check the output changes between the previously set tag and HEAD in the
-      :ref:`buildhistory <ref-classes-buildhistory>` output using ``git diff`` or ``buildhistory-diff``.
+      :ref:`ref-classes-buildhistory` output using ``git diff`` or ``buildhistory-diff``.
 
-   For more information on using :ref:`buildhistory <ref-classes-buildhistory>`, see
+   For more information on using :ref:`ref-classes-buildhistory`, see
    :ref:`dev-manual/build-quality:maintaining build output quality`.