Respond to the feedback on wheel stubs in the Rationale section

peps/pep-0759.rst

@@ -33,27 +33,22 @@ Rationale
 =========
 
 The Python Package Index, hosted at https://pypi.org, imposes `default limits
-<https://pypi.org/help/>`__ on upload artifact file size (100 MiB) and total
-project size (10 GiB). Most projects can comfortably fit within these limits
-during the lifetime of the project, through years of uploads. A few projects
-have encountered these limits, and have been granted both `file size
-exceptions <https://github.com/pypi/support/issues/4378>`__ and `project size
-exceptions <https://github.com/pypi/support/issues/4379>`__, allowing them to
-continue uploading new releases without having to take more drastic measures,
-such as removing files which may potentially still be in use by consumers
-(e.g. through version pins).
-
-A related workaround is the `"wheel stub"
-<https://github.com/wheel-next/wheel-stub>`__ approach, which provides an
-indirect link between PyPI and an external third party package index, where
-such limitations can be avoided. Wheel stubs are `source distributions
-<https://packaging.python.org/en/latest/specifications/source-distribution-format/>`__,
-a.k.a. "sdists" which utilize a :pep:`517` build backend that, instead of turning
-source code into a binary wheel, performs some logic to calculate the URL for
-an existing, externally hosted wheel to download.  Technically speaking, this
-satisfies the build backend contract, but the link between PyPI, the sdist,
-and the externally hosted wheel isn't evident, easily discoverable, or
-auditable.
+<https://pypi.org/help/>`__ on upload artifact file size (100 MiB) and total project size
+(10 GiB). Most projects can comfortably fit within these limits during the lifetime of the
+project, through years of uploads. A few projects have encountered these limits, and have
+been granted both file size and project size exceptions, allowing them to continue
+uploading new releases without having to take more drastic measures, such as removing
+files which may potentially still be in use by consumers (e.g. through version pins).
+
+A related workaround is the `"wheel stub" <https://github.com/wheel-next/wheel-stub>`__
+approach, which provides an indirect link between PyPI and an external third party package
+index, where such limitations can be avoided. Wheel stubs are :ref:`source distributions
+<packaging:source-distribution-format>` (a.k.a. "sdists") which utilize a :pep:`517` build
+backend that, instead of turning source code into a binary wheel, performs some logic to
+calculate the URL for an existing, externally hosted wheel to download and install.  This
+approach works, but it obscures the connection between PyPI, the sdist, and the externally
+hosted wheel, since there is no way to present this information to ``pip`` or other such
+tools.
 
 Historical context
 ==================