gawk: break unresolvable dependency cycle with glibc

[kgodara912]

The build graph contained a cycle that could not be resolved from prebuilt or PMC RPMs:

/sbin/ldconfig-RUN -> mpfr-RUN -> gawk-RUN -> /sbin/ldconfig-BUILD

glibc build-requires gawk, and gawk's explicit Requires: mpfr pulled in mpfr, whose %post scriptlet requires /sbin/ldconfig from glibc. gawk's own ldconfig scriptlets closed a second, shorter cycle the same way.

Drop the explicit gmp, mpfr and readline requires: RPM already generates the equivalent soname dependencies (libgmp.so.10, libmpfr.so.6, libreadline.so.8) at build time, but those are invisible to the spec-parsing grapher, so only the explicit ones create graph edges.

Drop the ldconfig scriptlets as well. gawk's only shared objects are loadable extensions under %{_libdir}/gawk/, which is not on the dynamic linker search path, so there is no shared library cache to refresh.

Bump release to 3.

Explanation:

The pipeline grapher fails with an unresolvable cycle:

PANI[0005][grapher] unfixable circular dependency in dependency graph
({/sbin/ldconfig--RUN<Meta>} --> {mpfr-4.2.1-1.azl3-RUN<Meta>} -->
{gawk-5.2.2-2.azl3-RUN<Meta>} --> {/sbin/ldconfig--BUILD<Build>} -->
{/sbin/ldconfig--RUN<Meta>}): cycle can't be resolved with prebuilt/PMC RPMs.

glibc build-requires gawk; gawk declared Requires: mpfr; mpfr's %post scriptlet
requires /sbin/ldconfig, which glibc provides. gawk's own %post -p /sbin/ldconfig
closed a second, shorter cycle the same way.

This cycle has existed for years. It was harmless because fixCyclesWithExistingRPMS
cut it by substituting a prebuilt gawk RPM. Once gawk itself was patched (CVEs in
5.2.2-2) no prebuilt of the new release existed, so there was nothing to cut with.
A local build passes because it can reuse the previously built gawk from the local cache.

Fix

1. Drop Requires: gmp, Requires: mpfr, Requires: readline >= 7.0.
2. Drop the %post/%postun -p /sbin/ldconfig scriptlets.
3. Bump to 5.2.2-3 and update the four toolchain/pkggen-core manifests.

Why this is safe

The grapher only sees dependencies written in the .spec. RPM's find-requires
generates the real runtime deps from linked ELF sonames at build time, and those are
invisible to the graph — so removing the redundant by-name tags breaks the graph edge
without weakening the package.

Verified on the built RPM:

$ rpm -qp --requires ../out/RPMS/x86_64/gawk-5.2.2-3.azl3.x86_64.rpm
/bin/sh
libc.so.6()(64bit)
libgmp.so.10()(64bit)
libm.so.6()(64bit)
libmpfr.so.6()(64bit)
libreadline.so.8()(64bit)
...

libgmp.so.10, libmpfr.so.6 and libreadline.so.8 are matched by the auto-generated
Provides of gmp, mpfr and readline. Note /sbin/ldconfig is gone, which is what breaks
the cycle. The soname deps are stricter than the old by-name tags, since they pin the
library ABI rather than just the package name.

Install still pulls the libraries in:

$ tdnf install gawk-5.2.2-3.azl3.x86_64.rpm
Installing/Updating: mpfr-4.2.1-1.azl3.x86_64
Installing/Updating: gawk-5.2.2-3.azl3.x86_64

$ rpm -q gmp readline
gmp-6.3.0-1.azl3.x86_64
readline-8.2-2.azl3.x86_64

Only mpfr is listed because gmp and readline were already present. Removing either is
still refused, since it would orphan gawk.

The ldconfig scriptlets were no-ops: gawk's only shared objects are its loadable
extensions under %{_libdir}/gawk/, which ldconfig never scans and which gawk
dlopen()s itself via AWKLIBPATH.

Feature parity is unaffected — there were no BuildRequires for gmp/mpfr/readline before
this change either, so the build environment and the resulting binary are identical to
5.2.2-2.

Buddy build