Use underscore instead of dash for the package information docs

In https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70537
we moved the docs from Omnibus into the GitLab project, but there
was a typo in the directory name.

doc/administration/consul.md

@@ -21,7 +21,7 @@ Before configuring Consul:
 
 1. Review the [reference architecture](reference_architectures/index.md#available-reference-architectures)
    documentation to determine the number of Consul server nodes you should have.
-1. If necessary, ensure the [appropriate ports are open](package-information/defaults.md#ports) in your firewall.
+1. If necessary, ensure the [appropriate ports are open](package_information/defaults.md#ports) in your firewall.
 
 ## Configure the Consul nodes
 

doc/administration/geo/index.md

@@ -138,7 +138,7 @@ The following table lists basic ports that must be open between the **primary**
 | 22               | 22                 | TCP          |
 | 5432             |                    | PostgreSQL   |
 
-See the full list of ports used by GitLab in [Package defaults](../package-information/defaults.md)
+See the full list of ports used by GitLab in [Package defaults](../package_information/defaults.md)
 
 NOTE:
 [Web terminal](../../ci/environments/index.md#web-terminals) support requires your load balancer to correctly handle WebSocket connections.

doc/administration/pages/index.md

@@ -1278,7 +1278,7 @@ in all of your GitLab Pages instances.
 
 ### 500 error with `securecookie: failed to generate random iv` and `Failed to save the session`
 
-This problem most likely results from an [out-dated operating system](../package-information/deprecated_os.md).
+This problem most likely results from an [out-dated operating system](../package_information/deprecated_os.md).
 The [Pages daemon uses the `securecookie` library](https://gitlab.com/search?group_id=9970&project_id=734943&repository_ref=master&scope=blobs&search=securecookie&snippets=false) to get random strings via [`crypto/rand` in Go](https://golang.org/pkg/crypto/rand/#pkg-variables).
 This requires the `getrandom` system call or `/dev/urandom` to be available on the host OS.
 Upgrading to an [officially supported operating system](https://about.gitlab.com/install/) is recommended.

doc/administration/postgresql/replication_and_failover.md

@@ -72,13 +72,13 @@ the PgBouncer service.
 
 ### Connection flow
 
-Each service in the package comes with a set of [default ports](../package-information/defaults.md#ports). You may need to make specific firewall rules for the connections listed below:
+Each service in the package comes with a set of [default ports](../package_information/defaults.md#ports). You may need to make specific firewall rules for the connections listed below:
 
-- Application servers connect to either PgBouncer directly via its [default port](../package-information/defaults.md) or via a configured Internal Load Balancer (TCP) that serves multiple PgBouncers.
-- PgBouncer connects to the primary database servers [PostgreSQL default port](../package-information/defaults.md)
+- Application servers connect to either PgBouncer directly via its [default port](../package_information/defaults.md) or via a configured Internal Load Balancer (TCP) that serves multiple PgBouncers.
+- PgBouncer connects to the primary database servers [PostgreSQL default port](../package_information/defaults.md)
 - Patroni actively manages the running PostgreSQL processes and configuration.
-- PostgreSQL secondaries connect to the primary database servers [PostgreSQL default port](../package-information/defaults.md)
-- Consul servers and agents connect to each others [Consul default ports](../package-information/defaults.md)
+- PostgreSQL secondaries connect to the primary database servers [PostgreSQL default port](../package_information/defaults.md)
+- Consul servers and agents connect to each others [Consul default ports](../package_information/defaults.md)
 
 ## Setting it up
 
@@ -306,7 +306,7 @@ If you enable Monitoring, it must be enabled on **all** database servers.
 #### Enable TLS support for the Patroni API
 
 By default, Patroni's [REST API](https://patroni.readthedocs.io/en/latest/rest_api.html#rest-api) is served over HTTP.
-You have the option to enable TLS and use HTTPS over the same [port](../package-information/defaults.md).
+You have the option to enable TLS and use HTTPS over the same [port](../package_information/defaults.md).
 
 To enable TLS, you need PEM-formatted certificate and private key files. Both files must be readable by the PostgreSQL user (`gitlab-psql` by default, or the one set by `postgresql['username']`):
 
@@ -789,7 +789,7 @@ You do not need any special consideration for Patroni while provisioning your da
 
 Patroni monitors the cluster and handles any failover. When the primary node fails it works with Consul to notify PgBouncer. On failure, Patroni handles the transitioning of the old primary to a replica and rejoins it to the cluster automatically.
 
-With Patroni, the connection flow is slightly different. Patroni on each node connects to Consul agent to join the cluster. Only after this point it decides if the node is the primary or a replica. Based on this decision, it configures and starts PostgreSQL which it communicates with directly over a Unix socket. This means that if the Consul cluster is not functional or does not have a leader, Patroni and by extension PostgreSQL does not start. Patroni also exposes a REST API which can be accessed via its [default port](../package-information/defaults.md)
+With Patroni, the connection flow is slightly different. Patroni on each node connects to Consul agent to join the cluster. Only after this point it decides if the node is the primary or a replica. Based on this decision, it configures and starts PostgreSQL which it communicates with directly over a Unix socket. This means that if the Consul cluster is not functional or does not have a leader, Patroni and by extension PostgreSQL does not start. Patroni also exposes a REST API which can be accessed via its [default port](../package_information/defaults.md)
 on each node.
 
 ### Check replication status

doc/development/deprecation_guidelines/index.md

@@ -32,6 +32,6 @@ It also should be [deprecated in advance](https://about.gitlab.com/handbook/mark
 
 For API removals, see the [GraphQL](../../api/graphql/index.md#deprecation-and-removal-process) and [GitLab API](../../api/index.md#compatibility-guidelines) guidelines.
 
-For configuration removals, see the [Omnibus deprecation policy](../../administration/package-information/deprecation_policy.md).
+For configuration removals, see the [Omnibus deprecation policy](../../administration/package_information/deprecation_policy.md).
 
 For versioning and upgrade details, see our [Release and Maintenance policy](../../policy/maintenance.md).

doc/development/pipelines.md

@@ -450,7 +450,7 @@ In addition, there are a few circumstances where we would always run the full Je
 ### PostgreSQL versions testing
 
 Our test suite runs against PG12 as GitLab.com runs on PG12 and
-[Omnibus defaults to PG12 for new installs and upgrades](../administration/package-information/postgresql_versions.md),
+[Omnibus defaults to PG12 for new installs and upgrades](../administration/package_information/postgresql_versions.md),
 Our test suite is currently running against PG11, since GitLab.com still runs on PG11.
 
 We do run our test suite against PG11 on nightly scheduled pipelines as well as upon specific
@@ -467,7 +467,7 @@ database library changes in MRs and `main` pipelines (with the `rspec db-library
 
 #### Long-term plan
 
-We follow the [PostgreSQL versions shipped with Omnibus GitLab](../administration/package-information/postgresql_versions.md):
+We follow the [PostgreSQL versions shipped with Omnibus GitLab](../administration/package_information/postgresql_versions.md):
 
 | PostgreSQL version | 13.11 (April 2021)     | 13.12 (May 2021)       | 14.0 (June 2021?)      |
 | -------------------| ---------------------- | ---------------------- | ---------------------- |

doc/install/docker.md

@@ -368,7 +368,7 @@ You can then access your GitLab instance at `http://198.51.100.1/` and `https://
 
 ### Expose GitLab on different ports
 
-GitLab will occupy [some ports](../administration/package-information/defaults.md)
+GitLab will occupy [some ports](../administration/package_information/defaults.md)
 inside the container.
 
 If you want to use a different host port than `80` (HTTP) or `443` (HTTPS),

doc/install/requirements.md

@@ -36,7 +36,7 @@ For the installation options, see [the main installation page](index.md).
 Installation of GitLab on these operating systems is possible, but not supported.
 Please see the [installation from source guide](installation.md) and the [installation guides](https://about.gitlab.com/install/) for more information.
 
-Please see [OS versions that are no longer supported](../administration/package-information/deprecated_os.md) for Omnibus installs page
+Please see [OS versions that are no longer supported](../administration/package_information/deprecated_os.md) for Omnibus installs page
 for a list of supported and unsupported OS versions as well as the last support GitLab version for that OS.
 
 ### Microsoft Windows

doc/update/package/index.md

@@ -183,7 +183,7 @@ To download and install GitLab:
 
 ### GitLab 13.7 and later unavailable on Amazon Linux 2
 
-Amazon Linux 2 is not an [officially supported operating system](../../administration/package-information/deprecated_os.md#supported-operating-systems).
+Amazon Linux 2 is not an [officially supported operating system](../../administration/package_information/deprecated_os.md#supported-operating-systems).
 However, in past the [official package installation script](https://packages.gitlab.com/gitlab/gitlab-ee/install)
 installed the `el/6` package repository if run on Amazon Linux. From GitLab 13.7, we no longer
 provide `el/6` packages so administrators must run the [installation script](https://packages.gitlab.com/gitlab/gitlab-ee/install)

doc/update/plan_your_upgrade.md

@@ -18,7 +18,7 @@ General notes:
   to create your plan, share details of your architecture, including:
   - How is GitLab installed?
   - What is the operating system of the node?
-    (check [OS versions that are no longer supported](../administration/package-information/deprecated_os.md) to confirm that later updates are available).
+    (check [OS versions that are no longer supported](../administration/package_information/deprecated_os.md) to confirm that later updates are available).
   - Is it a single-node or a multi-node setup? If multi-node, share any architectural details about each node with us.
   - Are you using [GitLab Geo](../administration/geo/index.md)? If so, share any architectural details about each secondary node.
   - What else might be unique or interesting in your setup that might be important for us to understand?
@@ -112,7 +112,7 @@ to your instance and then upgrade it for any relevant features you're using.
   - [Determine what upgrade path](index.md#upgrade-paths) to follow.
   - Account for any [version-specific update instructions](index.md#version-specific-upgrading-instructions).
   - Account for any [version-specific changes](package/index.md#version-specific-changes).
-  - Check the [OS compatibility with the target GitLab version](../administration/package-information/deprecated_os.md).
+  - Check the [OS compatibility with the target GitLab version](../administration/package_information/deprecated_os.md).
 - Due to background migrations, plan to pause any further upgrades after upgrading
   to a new major version.
   [All migrations must finish running](index.md#checking-for-background-migrations-before-upgrading)
@@ -123,7 +123,7 @@ to your instance and then upgrade it for any relevant features you're using.
 - About PostgreSQL:
   - On the top bar, select **Menu > Admin**, and look for the version of
     PostgreSQL you are using.
-    If [a PostgreSQL upgrade is needed](../administration/package-information/postgresql_versions.md),
+    If [a PostgreSQL upgrade is needed](../administration/package_information/postgresql_versions.md),
     account for the relevant
     [packaged](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server)
     or [non-packaged](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-a-non-packaged-postgresql-database) steps.

doc/user/project/import/index.md

@@ -76,7 +76,7 @@ a self-managed instance from an old server to a new server.
 
 The backups produced don't depend on the operating system running GitLab. You can therefore use
 the restore method to switch between different operating system distributions or versions, as long
-as the same GitLab version [is available for installation](../../../administration/package-information/deprecated_os.md).
+as the same GitLab version [is available for installation](../../../administration/package_information/deprecated_os.md).
 
 To instead merge two self-managed GitLab instances together, use the instructions in
 [Migrate from self-managed GitLab to GitLab.com](#migrate-from-self-managed-gitlab-to-gitlabcom).