docs(build): point build-id comment at the merged VS Code precedent

Re-read the issues and linked PRs more carefully after a review
comment. The inline comment in both spec files cited
Azure/azure-cli#23798 as the canonical reference for the
`_build_id_links none` workaround, but that PR has been open
(not merged) since 2022; the azure-cli maintainers were actually
sceptical on the linked Azure/azure-cli#23559 discussion and
never integrated the fix.

The real precedent is microsoft/vscode#116105, which used the
exact same `%define _build_id_links none` line and was merged in
February 2021 to solve the same class of conflict between the
`code` and `code-insiders` RPMs (both ship the same Electron
binary). VS Code has been shipping this workaround for nearly
five years with no reported side effects.

Update both spec file comments to reference the merged VS Code
fix as the primary precedent and keep azure-cli only as "this is
where the conflict in issue #979 was reported", not as a
canonical-fix citation. Also broaden the example of the
colliding shared object beyond libpython - in practice the same
thing happens to ordinary compiled wheels like charset_normalizer
(see the datadog-agent reports on Azure/azure-cli#23559).

No code change, no CHANGELOG churn.

Author: markuslf

build/linuxfabrik-monitoring-plugins.el.spec

@@ -11,12 +11,15 @@ Packager:       info@linuxfabrik.ch
 # the main package. RPM installs one such symlink for every shared
 # object in the bundled venv, and the build-id hash is computed from
 # the .so content, so two independent RPMs that happen to ship the
-# same upstream binary (e.g. a bundled libpython) end up fighting over
-# the same symlink path and `dnf install` aborts with a file
-# conflict. Setting `_build_id_links` to `none` keeps the debuginfo
-# extraction running in general but tells rpmbuild to skip this
-# specific symlink creation. See issue #979 and the same workaround
-# in the azure-cli project at Azure/azure-cli#23798.
+# same upstream binary (e.g. one also carrying a copy of libpython or
+# of a compiled Python extension like charset_normalizer) end up
+# fighting over the same symlink path and `dnf install` aborts with
+# a file conflict. Setting `_build_id_links` to `none` tells rpmbuild
+# to skip the symlink creation while leaving the rest of the package
+# build untouched. See issue #979 for the conflict against azure-cli
+# and Microsoft VS Code microsoft/vscode#116105 for the same
+# workaround (merged 2021) against the same class of problem between
+# `code` and `code-insiders`.
 %define _build_id_links none
 
 Source0:        https://github.com/Linuxfabrik/monitoring-plugins/archive/refs/tags/v%{version}.tar.gz

build/linuxfabrik-monitoring-plugins.sle.spec

@@ -11,12 +11,15 @@ Packager:       info@linuxfabrik.ch
 # the main package. RPM installs one such symlink for every shared
 # object in the bundled venv, and the build-id hash is computed from
 # the .so content, so two independent RPMs that happen to ship the
-# same upstream binary (e.g. a bundled libpython) end up fighting over
-# the same symlink path and `dnf install` aborts with a file
-# conflict. Setting `_build_id_links` to `none` keeps the debuginfo
-# extraction running in general but tells rpmbuild to skip this
-# specific symlink creation. See issue #979 and the same workaround
-# in the azure-cli project at Azure/azure-cli#23798.
+# same upstream binary (e.g. one also carrying a copy of libpython or
+# of a compiled Python extension like charset_normalizer) end up
+# fighting over the same symlink path and `dnf install` aborts with
+# a file conflict. Setting `_build_id_links` to `none` tells rpmbuild
+# to skip the symlink creation while leaving the rest of the package
+# build untouched. See issue #979 for the conflict against azure-cli
+# and Microsoft VS Code microsoft/vscode#116105 for the same
+# workaround (merged 2021) against the same class of problem between
+# `code` and `code-insiders`.
 %define _build_id_links none
 
 Source0:        https://github.com/Linuxfabrik/monitoring-plugins/archive/refs/tags/v%{version}.tar.gz