Replace <path> by <c> throughout.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>

7 files changed, 42 insertions, 42 deletions

diff --git a/appendices/contributing/devbook-guide/text.xml b/appendices/contributing/devbook-guide/text.xml
index 29be787..d39e794 100644
--- a/appendices/contributing/devbook-guide/text.xml
+++ b/appendices/contributing/devbook-guide/text.xml
@@ -215,7 +215,7 @@ Now, here's how the <c>&lt;body&gt;</c> element above is rendered:
 </p>
 
 <p>
-This is a paragraph.  <path>/etc/passwd</path> is a file.
+This is a paragraph.  <c>/etc/passwd</c> is a file.
 <uri>https://forums.gentoo.org</uri> is my favorite web site.
 Type <c>ls</c> if you feel like it.  I <e>really</e> want to go to sleep now.
 </p>
diff --git a/ebuild-maintenance/git/text.xml b/ebuild-maintenance/git/text.xml
index ba811ac..864036e 100644
--- a/ebuild-maintenance/git/text.xml
+++ b/ebuild-maintenance/git/text.xml
@@ -175,7 +175,7 @@ do not split relevant or interdependent changes within a single package.
 <li>
 Avoid creating commits introducing a temporary breakage. Unless impossible,
 add packages in dependency install order. Add licenses before the packages
-needing them. Commit <path>package.mask</path> and other profile changes before
+needing them. Commit <c>package.mask</c> and other profile changes before
 ebuilds relying on them. Usually it is also acceptable to include those changes
 along with the commit adding the package.
 </li>
diff --git a/ebuild-maintenance/maintenance-tasks/text.xml b/ebuild-maintenance/maintenance-tasks/text.xml
index 1fa67dc..f66d636 100644
--- a/ebuild-maintenance/maintenance-tasks/text.xml
+++ b/ebuild-maintenance/maintenance-tasks/text.xml
@@ -32,10 +32,10 @@ select all possible fields, then submit the query. For you lazy people, click
 
 <p>
 In general, the Gentoo repository should only be used for storing
-<path>.ebuild</path> files, as well as any relatively small companion
+<c>.ebuild</c> files, as well as any relatively small companion
 files, such as patches or sample configuration files. These types of
-files should be placed in the <path>mycat/mypkg/files</path> directory
-to keep the main <path>mycat/mypkg</path> directory uncluttered.
+files should be placed in the <c>mycat/mypkg/files</c> directory
+to keep the main <c>mycat/mypkg</c> directory uncluttered.
 Exceptions to this rule are for larger patch files (we recommend this
 for patches above 20KB) which should be distributed as tarballs via the
 <uri link="::general-concepts/mirrors/#suitable-download-hosts">Gentoo
@@ -99,23 +99,23 @@ work on those architectures.
 
 <p>
 As noted earlier, under each package subdirectory is
-a <path>files/</path> directory. Any patches, configuration files, or
+a <c>files/</c> directory. Any patches, configuration files, or
 other ancillary files your package might require should be added to
 this directory; any files bigger than 20KB-or-so should go to the
 mirrors to lower the amount of (unneeded) files our users have to
 download. You may want to consider naming patches you create yourself
 just to get your package to build with a version-specific name, such
-as <path>mypkg-1.0-gentoo.diff</path>, or more
-simply, <path>1.0-gentoo.diff</path>.  Also note that the
-<path>gentoo</path> extension informs people that this patch was created
+as <c>mypkg-1.0-gentoo.diff</c>, or more
+simply, <c>1.0-gentoo.diff</c>.  Also note that the
+<c>gentoo</c> extension informs people that this patch was created
 by us, the Gentoo Linux developers, rather than having been grabbed from a
 mailing list or somewhere else. Again, you should not compress these
 patches.
 </p>
 
 <p>
-Consider prefixing or suffixing (such as <path>mypkg-1.0</path>) every file
-you put into the <path>files/</path> directory, so that the files used for
+Consider prefixing or suffixing (such as <c>mypkg-1.0</c>) every file
+you put into the <c>files/</c> directory, so that the files used for
 each individual version on an ebuild are distinguishable from one another, and
 so that the changes between different revisions are visible.  This is generally
 a really good idea :).  You may want to use a different suffix if you wish to
@@ -123,8 +123,8 @@ convey more meaning with the patch name.
 </p>
 
 <p>
-If you have many files that should go into the <path>files/</path> directory,
-consider creating subdirectories such as <path>files/1.0/</path> and putting the
+If you have many files that should go into the <c>files/</c> directory,
+consider creating subdirectories such as <c>files/1.0/</c> and putting the
 relevant files in the appropriate subdirectory.  If you use this method,
 you do not need to add version information to the names of the files,
 which is often more convenient.
@@ -253,7 +253,7 @@ to be in very poor taste and may result in disciplinary action.
 Moving a package in the tree requires several operations. Firstly,
 the package directory needs to be moved to the correct category
 using <c>git mv</c>. After this, a new entry needs to be added to
-the latest file in <path>profiles/updates/</path> in the
+the latest file in <c>profiles/updates/</c> in the
 following format:
 </p>
 
@@ -269,10 +269,10 @@ the package to be moved) need to be updated properly.
 </p>
 
 <p>
-Next is checking the files under <path>profiles/</path> such as
-<path>profiles/package.mask</path> and update them to reflect the ebuild
+Next is checking the files under <c>profiles/</c> such as
+<c>profiles/package.mask</c> and update them to reflect the ebuild
 move. Various eclasses automatically provide some of the dependencies upon
-inherit, so the files under <path>eclass/</path> should be checked and updated
+inherit, so the files under <c>eclass/</c> should be checked and updated
 properly. If the package metadata.xml has tags with <c>restrict</c>
 attribute, they should be updated to reflect the move. The
 metadata.xml for various packages may contain references to the
@@ -283,8 +283,8 @@ related to the package should be updated.
 
 <p>
 Here is an example where the package
-<path>net-misc/fwbuilder</path> is transparently moved to
-<path>net-firewall/fwbuilder</path>:
+<c>net-misc/fwbuilder</c> is transparently moved to
+<c>net-firewall/fwbuilder</c>:
 </p>
 
 <ol>
@@ -292,14 +292,14 @@ Here is an example where the package
   <li>
     <p>
       Add the following entry to the latest file in
-      <path>profile/updates/</path>:
+      <c>profile/updates/</c>:
     </p>
     <p><c>move net-misc/fwbuilder net-firewall/fwbuilder</c></p>
   </li>
   <li>Update the reverse dependencies of the package</li>
   <li>
-    Update <path>profiles/package.mask</path> and other related files under
-    <path>profiles/</path>
+    Update <c>profiles/package.mask</c> and other related files under
+    <c>profiles/</c>
   </li>
   <li>Check the eclasses that may be referencing the package</li>
   <li>
@@ -348,7 +348,7 @@ Date:   Wed Dec 18 19:56:03 2019 +0100
 <p>
 The process for changing the ebuild's SLOT is very similar to the
 previous process.  Besides changing the SLOT in the ebuild file, you
-also need to create a new entry in <path>profiles/updates/</path> in
+also need to create a new entry in <c>profiles/updates/</c> in
 the Gentoo repository in the following format:
 </p>
 
@@ -358,7 +358,7 @@ slotmove app-text/gtkspell 0 2
 
 <p>
 Make sure that you have fixed all the reverse dependencies and that
-you have updated every file in <path>profiles/</path> directory that
+you have updated every file in <c>profiles/</c> directory that
 happens to contain an entry which may be affected by your change.
 </p>
 
@@ -421,7 +421,7 @@ When removing packages follow these steps:
 </ol>
 
 <p>
-Here is a list of commands that will delete <path>dev-util/pmk</path>
+Here is a list of commands that will delete <c>dev-util/pmk</c>
 from the tree:
 </p>
 
@@ -459,9 +459,9 @@ already provided by another package (detectable with
 situation before you can commit the ebuild or, if you encounter this
 with an existing package, file a bug about that package (see below for
 a few exceptions). The reason file conflicts are critical is because
-if "foo" provides the file <path>/usr/bin/example</path> and "bar" is
+if "foo" provides the file <c>/usr/bin/example</c> and "bar" is
 going to overwrite it, and later "bar" is unmerged, Portage will remove
-<path>/usr/bin/example</path> and it is therefore likely it will break
+<c>/usr/bin/example</c> and it is therefore likely it will break
 "foo".
 </p>
 
diff --git a/ebuild-writing/common-mistakes/text.xml b/ebuild-writing/common-mistakes/text.xml
index 6846ed1..12e14c1 100644
--- a/ebuild-writing/common-mistakes/text.xml
+++ b/ebuild-writing/common-mistakes/text.xml
@@ -317,14 +317,14 @@ Another common mistake users make when submitting ebuilds is supplying an
 invalid license. For example, <c>GPL</c> is not a valid license. You need to
 specify <c>GPL-1</c> or <c>GPL-2</c>. Same with <c>LGPL</c>. Make sure the
 license you use in the <c>LICENSE</c> field is something that exists in
-the <path>licenses</path> directory. As a tip, check the <path>COPYING</path>
+the <c>licenses</c> directory. As a tip, check the <c>COPYING</c>
 in a source tarball for the license. If a package does not specify it
 uses <c>GPL-1</c> or <c>GPL-2</c>, it is very likely it uses <c>GPL-2</c>.
 </p>
 
 <p>
 If the license for the package you submit is unique and not in
-<path>licenses/</path>, then you must submit the new license in a
+<c>licenses/</c>, then you must submit the new license in a
 separate file.
 </p>
 
@@ -413,7 +413,7 @@ implied already, you should only add it if it is something other than
 
 <p>
 If your package has documentation, make sure you install it using <c>dodoc</c>
-or in <path>/usr/share/doc/${PF}</path>. Remember to check for errors when
+or in <c>/usr/share/doc/${PF}</c>. Remember to check for errors when
 running <c>dodoc</c>/<c>doins</c>.
 </p>
 
diff --git a/ebuild-writing/misc-files/metadata/text.xml b/ebuild-writing/misc-files/metadata/text.xml
index a89a512..4d2d7cf 100644
--- a/ebuild-writing/misc-files/metadata/text.xml
+++ b/ebuild-writing/misc-files/metadata/text.xml
@@ -52,7 +52,7 @@ metadata.xml:
     <c>&lt;catmetadata&gt;</c>
   </ti>
   <ti>
-    This is the root element of the <path>metadata.xml</path> file for
+    This is the root element of the <c>metadata.xml</c> file for
     categories. It has no attributes. It contains a number of
     <c>&lt;longdescription&gt;</c> tags, each for a different language.
   </ti>
@@ -62,7 +62,7 @@ metadata.xml:
     <c>&lt;pkgmetadata&gt;</c>
   </ti>
   <ti>
-    This is the root element of the <path>metadata.xml</path> file for
+    This is the root element of the <c>metadata.xml</c> file for
     packages. It has no attributes. The following subtags are
     allowed:
     <c>&lt;longdescription&gt;</c>,
@@ -236,7 +236,7 @@ metadata.xml:
   <ti><c>&lt;cat&gt;</c></ti>
   <ti>
     This tag contains a valid category name as defined in
-    <path>profiles/categories</path>.
+    <c>profiles/categories</c>.
   </ti>
 </tr>
 </table>
@@ -389,8 +389,8 @@ these files verbatim and should be taken as hypothetical examples.
 
 <p>
 For the first example, a package maintained by a single project is
-presented. It is a simplified version of <path>metadata.xml</path> for
-the package <path>app-office/libreoffice</path>. The package
+presented. It is a simplified version of <c>metadata.xml</c> for
+the package <c>app-office/libreoffice</c>. The package
 maintainer is identified by the email address <c>office@gentoo.org</c>
 with the name <c>Gentoo Office Project</c> as specified in the
 optional &lt;name&gt; subtag. It also provides a long package
@@ -453,8 +453,8 @@ projects listing</uri> available on the Gentoo Wiki:
 <body>
 
 <p>
-The second example is formed after the <path>metadata.xml</path> of
-<path>sys-apps/portage</path>. It lists multiple maintainers where one
+The second example is formed after the <c>metadata.xml</c> of
+<c>sys-apps/portage</c>. It lists multiple maintainers where one
 is a developer and the other is a project. It illustrates how local
 USE flag descriptions are specified and also contains an upstream
 element. It is also worth pointing out the use of <c>mailto:</c>
@@ -502,7 +502,7 @@ as opposed to a URL. Conversely, email addresses specified in the
 <p>
 This example splits the maintainership based on package versions using
 the attribute <c>restrict</c>. According to the
-<path>metadata.xml</path> of <path>sys-boot/grub</path>, the ebuilds
+<c>metadata.xml</c> of <c>sys-boot/grub</c>, the ebuilds
 for version 2 and above are maintained by floppym@gentoo.org whereas
 earlier versions are maintained by the Gentoo Base System
 project. Note the use of "&amp;gt;" as opposed to "&gt;" in
@@ -571,7 +571,7 @@ is demonstrated.
 <p>
 The main focus of this example is to demonstrate how slots and
 subslots are specified, by examining the metadata of
-<path>media-libs/libpng</path>. There may be multiple reasons for
+<c>media-libs/libpng</c>. There may be multiple reasons for
 slotting depending on the nature of the package. For this particular
 package, it can be seen that the slots are used to provide different
 versions of the library with varying binary compatibility and that
diff --git a/general-concepts/manifest/text.xml b/general-concepts/manifest/text.xml
index 1b8120b..ace785d 100644
--- a/general-concepts/manifest/text.xml
+++ b/general-concepts/manifest/text.xml
@@ -56,10 +56,10 @@ Portage Configuration:
 
 <ul>
   <li>
-    Set <path>PORTAGE_GPG_DIR</path> to your <path>~/.gnupg/</path> directory
+    Set <c>PORTAGE_GPG_DIR</c> to your <c>~/.gnupg/</c> directory
     (or the directory where the keyring with your new key is).
   </li>
-  <li>Set <path>PORTAGE_GPG_KEY</path> to the key id of your new key.</li>
+  <li>Set <c>PORTAGE_GPG_KEY</c> to the key id of your new key.</li>
   <li>Set FEATURES="sign".</li>
 </ul>
 
diff --git a/general-concepts/projects/text.xml b/general-concepts/projects/text.xml
index ee501b9..c0a28ca 100644
--- a/general-concepts/projects/text.xml
+++ b/general-concepts/projects/text.xml
@@ -77,7 +77,7 @@ modifying the member list.
 
 <p>
 Developers should remember to add themselves to the alias by editing
-<c><path>/var/mail/alias/misc/&lt;alias name&gt;</path></c> on
+<c>/var/mail/alias/misc/&lt;alias name&gt;</c> on
 dev.gentoo.org. For example, the alias for the Devmanual project is
 located at <c>/var/mail/alias/misc/devmanual</c>, which corresponds to
 the project's email address <c>devmanual@gentoo.org</c>.