TASK: fix libxcrypt-compat in ELN (Extras)

[yselkowitz]

What does the ELN SIG need to do?

While libxcrypt-compat is officially unwanted in RHEL 11, nbdkit-vddk-plugin still requires it, and that dependency is out of our control. Additionally, because libxcrypt-compat Requires: libxcrypt AND libxcrypt Obsoletes: libxcrypt-compat < VERSION-RELEASE, it requires bootstrapping to build libxcrypt-compat from libxcrypt-epel and everything breaks of libxcrypt-compat's NVR falls behind libxcrypt.

In order to fix this, can we consider the following:

• Can the Release of libxcrypt-epel be raised to e.g. 100, so that it won't fall behind libxcrypt?
• Additionally, should we try to drop the obsoletes for RHEL libxcrypt, as it doesn't make sense because EPEL may provide it?
• Does libxcrypt-compat really need to Requires: libxcrypt?

/cc @michel-slm @davide125

[michel-slm]

For the first two points - yes, absolutely. The obsoletes should be either dropped, or fixed - it should obsolete the version-release lesser than the first time -compat is dropped but no higher

And we can bump and rebuild for now - but should also check if the Requires is still necessary.

[yselkowitz]

Following up on last week's discussion, I don't see any evidence that the compat library depends on the main one, it just compiles the same code with different options. Therefore, the Requires: libxcrypt seems unnecessary, although that still leaves the conflict between BuildRequires: gnupg2 (which pulls in libxcrypt) and BuildRequires: libxcrypt-compat for that one test. Is that test worth the need to rebootstrap for each bump?

[yselkowitz]

https://src.fedoraproject.org/rpms/libxcrypt-epel/pull-request/1

[yselkowitz]

The package still needs to be kept ahead of libxcrypt NVR-wise, but it is buildable and installable again.