Added uncompress+file checks

[rincebrain]

(Once this gets signoff from people as a reasonable idea, I'll go make a PR for the build docs and bb-dependencies.sh to add the "ncompress" package for RPM distro instructions. At this rate, I'll soon have just added * to the install command...)

Motivation and Context

Having an old enough version of "file" and no "uncompress" program installed can cause rpmbuild as root to crash and mangle rpmdb, including on latest CentOS 8. "Oops."

As a brief summary of places this does or doesn't occur:

• 5.37 is the first release of upstream file that has this fixed (though, amusingly, it was not patched because of incorrectness, but for performance reasons)
• Debian-alikes ship "uncompress" as a copy of "gunzip" (Debian hardlinks it; Ubuntu just copies it), so this never comes up even though buster has an old enough version (5.35) of file.
• CentOS 7 has an ancient version of file (5.11), but this never happened in >50 runs when it usually takes 10 or fewer on vulnerable platforms; I'm going to conclude that it's because there was nontrivial churn and restructuring in the guilty function (uncompressbuf in compress.c)
• CentOS 8 has a vulnerable version (5.33), and does crash and burn sometimes.
• Fedora 29 has a vulnerable version (5.34) and crashes and burns
• Fedora 30 had a vulnerable version (5.36) but shipped a patched version
• Fedora 34 is too new (5.39)
• FreeBSD never cares, since it's not calling rpmbuild

(See also: #12071 and #12168)

Description

Added checks for file's version and uncompress's existence, then something that checks if file's major version is 5 and minor is less than 37; if so, and uncompress is absent, error out if attempting to build any rpm targets.

I also added checks to the RPM specfiles to require ncompress (a package which provides an uncompress on RPM distros) if on an EL distro <= 8 or a Fedora distro <= 30, to catch the odd case where someone runs ./configure and then uninstalls uncompress.

(If/when CentOS 8 ships a patched version of file, this could be revised to instead require >= patched version of file for each of Fedora and EL distros, but A) that hasn't happened yet and B) I have no idea how long it takes patched versions to propagate among EL derivatives)

How Has This Been Tested?

Built rpm-{kmod,utils} on:

• CentOS 7, with and without ncompress (it naturally refused with the latter)
• CentOS 8, with and without ncompress (same)
• Fedora 29, with and without ncompress (and again)
• Fedora 34, with and without ncompress (both work)
• Debian buster, with and without uncompress (the former works; the latter by renaming it out of the way; it fails)
• Debian bullseye, with uncompress (works)

Also a non-RPM build on FreeBSD 14-CURRENT x86_64 worked fine.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[behlendorf]

I've gone ahead and merged the buildbot change. If you can force update the PR we can verify all is well.

[rincebrain]

We'll see if this gets any traction, thanks.

Pushed.

Huh. I'll be kind of impressed if the sanity test failures are related, but I'll look at them.

edit: It looks like it's just a chain after a zfs destroy -r testpool/testfs1 got back EBUSY, which I'd be pretty impressed if this can cause.

[behlendorf]

Huh. I'll be kind of impressed if the sanity test failures are related, but I'll look at them.

Indeed! Lucky you, another rare glitch which occasionally pops up in the CI and nowhere else! But totally unrelated.

[rincebrain]

Yeah, at least whatever's happening to the FBSD 13 bot happens > 90% of the time (though I still haven't been able to reproduce it...it'd probably be simpler to open an AWS account and use the exact AMI.)

[behlendorf]

Speaking of the FreeBSD fixes, they've just been merged. So if you're game to rebase this one last time there's a chance all of the bots might pass. Though I don't think it's needed given the scope of this change.