ncompress deprecated in RHEL 8 and removed in RHEL 9

[mskarbek]

System information

Type	Version/Name
Distribution Name	RHEL
Distribution Version	9.0
Kernel Version	5.14.0-70.13.1
Architecture	x86_64
OpenZFS Version	2.1.4

Describe the problem you're observing

OpenZFS fails to build on RHEL 9 because of missing ncompress package. This package will not be provided by EPEL 9 nor CentOS Stream 9 repos.
Current, partial "solution" is to install ncompress form CentOS Stream 9 internal build env: https://kojihub.stream.centos.org/koji/buildinfo?buildID=12090 which is demonstrated here: https://github.com/zeet-cc/zfs-rpms/runs/6503222251?check_suite_focus=true#step:11:1.

Describe how to reproduce the problem

Try to build OpenZFS on RHEL 9.

Include any warning/errors/backtraces from the system logs

Wrote: /tmp/zfs-build--gyhXBGpB/SRPMS/zfs-2.1.4-1.el9.src.rpm
make[1]: Leaving directory '/root/zfs-2.1.4'
make  pkg="zfs" \
	def='--define "_without_debug 1" --define "_without_debuginfo 1" --define "_without_debug_kmem 1" --define "_without_debug_kmem_tracking 1" --define "_without_asan 1" --define "_initconfdir /etc/sysconfig" --define "_dracutdir /usr/lib/dracut" --define "_udevdir /lib/udev" --define "_udevruledir /lib/udev/rules.d" --with systemd --define "_unitdir /usr/lib/systemd/system" --define "_presetdir /usr/lib/systemd/system-preset" --define "_generatordir /usr/lib/systemd/system-generators"    ' rpm-common
make[1]: Entering directory '/root/zfs-2.1.4'
make[2]: Entering directory '/root/zfs-2.1.4'
make[2]: Leaving directory '/root/zfs-2.1.4'
Installing zfs-2.1.4-1.el9.src.rpm
warning: line 129: It's not recommended to have unversioned Obsoletes: Obsoletes:      spl
warning: line 178: It's not recommended to have unversioned Obsoletes: Obsoletes:      libzpool2
warning: line 179: It's not recommended to have unversioned Obsoletes: Obsoletes:      libzpool4
warning: line 195: It's not recommended to have unversioned Obsoletes: Obsoletes:      libnvpair1
warning: line 213: It's not recommended to have unversioned Obsoletes: Obsoletes:      libuutil1
warning: line 239: It's not recommended to have unversioned Obsoletes: Obsoletes:      libzfs2
warning: line 240: It's not recommended to have unversioned Obsoletes: Obsoletes:      libzfs4
warning: line 262: It's not recommended to have unversioned Obsoletes: Obsoletes:      zfs-devel
warning: line 263: It's not recommended to have unversioned Obsoletes: Obsoletes:      libzfs2-devel
warning: line 264: It's not recommended to have unversioned Obsoletes: Obsoletes:      libzfs4-devel
error: Failed build dependencies:
	ncompress is needed by zfs-2.1.4-1.el9.x86_64
make[1]: *** [Makefile:1677: rpm-common] Error 1
make[1]: Leaving directory '/root/zfs-2.1.4'
make: *** [Makefile:1632: rpm-utils] Error 2

Red Hat bugzilla ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2088305#c1

[snehring]

Adding --with-spec=redhat to the configure gets past this for me.

[snehring]

Wait, never mind, that was with the rpm-kmod target after running the default target, not the rpm target.

[behlendorf]

Thanks for letting us know. It sounds like we're going to need to drop this indirect dependency at least for RHEL9. This was added in PR #13480 to head off some unfortunate issues when building as root. @rincebrain what do you think about just reverting this commit?

[rincebrain]

Why not just do what I originally proposed and make the dependency conditional on RHEL version? I don't believe I ever got a reply on the bug I opened suggesting they've fixed this in older releases...

…

On Fri, May 20, 2022 at 1:53 PM Brian Behlendorf ***@***.***> wrote: Thanks for letting us know. It sounds like we're going to need to drop this indirect dependency at least for RHEL9. This was added in PR #13480 <#13480> to head off some unfortunate issues when building as root. @rincebrain <https://github.com/rincebrain> what do you think about just reverting this commit? — Reply to this email directly, view it on GitHub <#13480 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUI7PUOMAIN35GLCAAE2LVK7GTHANCNFSM5WL344SQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[behlendorf]

That's certainly an option, I suppose my only concern would be if we'll just end up running in to this again if/when other distributions drop the package. But who know what they might do, so I'd be good with just making it a dependency for <= RHEL8.

[rincebrain]

How many other distros ship RPM and might drop this?

OUEL or however they pronounce it mostly just takes RHEL packages, so they'll presumably match the same rule, Fedora already shipped fixed file versions in every not EOL Fedora, and RHEL is where we're at now.

I guess SuSE might break it and we'll have to revise this once more, but that's not so bad.

[mskarbek]

How many other distros ship RPM and might drop this?

Every RHEL 9 rebuild so Oracle Linux, Alma Linux, Rocky, whatever more there is, they will follow. Also, CentOS Stream 9 which is now RHEL 9 upstream.

[rincebrain]

How many other distros ship RPM and might drop this?

Every RHEL 9 rebuild so Oracle Linux, Alma Linux, Rocky, whatever more there is, they will follow. Also, CentOS Stream 9 which is now RHEL 9 upstream.

Yes, and how many of them don't match against a rule for EL major version, was my point.

[Conan-Kudo]

OpenZFS fails to build on RHEL 9 because of missing ncompress package. This package will not be provided by EPEL 9 nor CentOS Stream 9 repos.

Why can't ncompress be shipped in EPEL? If it's not in the shipped content for RHEL, it's eligible to be shipped in EPEL.

[rincebrain]

It could, but it's not necessary - it was to workaround a case where libmagic did something bonkers if it tried to process a specific type of compressed file and there was no program to handle it.

I have a PR I'll open shortly to change the dependency for RHEL-alikes, I'm just letting it run through the test suites to see if anything else is obviously broken on RHEL9 before opening it.

[Conan-Kudo]

I've been building OpenZFS for CentOS/RHEL 9 for a while and never encountered a problem omitting ncompress, so I think we're in a good shape dropping it...

[rincebrain]

Well, yes - I should have been more explicit, the specific libmagic bug is long since fixed in the version differences between 8 and 9.

[clarejor]

I've been building OpenZFS for CentOS/RHEL 9 for a while and never encountered a problem omitting ncompress, so I think we're in a good shape dropping it...

How did you work around it? I tried installing ncompress from the "CentOS Stream 9 internal build env" as described by the OP but still got build errors.

[Conan-Kudo]

My packaging never included ncompress as I never encountered the problem that added that build dependency in the first place.

[rincebrain]

Yeah, the problem was (from memory, so apologies if I misspeak) that if you had a certain kind of compressed archive, and rpm tried to inspect it during rpmbuild but you didn't have e.g. ncompress installed to handle it, libmagic would call the global version of the exit call, rather than "end this thread", and thus rpmbuild would die in a fire, and possibly leave your RPM db in an inconsistent state.

And if you were running rpmbuild as root, well...that wasn't just your local user rpmdb it ran against. Oops.

In any case, #13490 or something like it would resolve this without reintroducing the option for this to happen again, which I am personally keen to avoid as we did have several independent reports of people mangling their systems with this...

[Conan-Kudo]

And if you were running rpmbuild as root, well...that wasn't just your local user rpmdb it ran against. Oops.

Holy crap what?! Is there a Red Hat bug for this?

[rincebrain]

Yup. Or perhaps you'd like the one from Fedora.

#12173 has more details on our side.

[Conan-Kudo]

I will see about getting this fixed in CentOS Stream 8. This kind of problem is absolutely crap. It looks like it was fixed in Fedora, so it should be straightforward to fix in RHEL/CentOS 8.

[rincebrain]

Yeah, it's nasty playing whack-a-mole, but it seems like the least bad option (to me).

…

On Fri, May 20, 2022 at 2:42 PM Brian Behlendorf ***@***.***> wrote: That's certainly an option, I suppose my only concern would be if we'll just end up running in to this again if/when other distributions drop the package. But who know what they might do, so I'd be good with just making it a dependency for <= RHEL8. — Reply to this email directly, view it on GitHub <#13480 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUI7JTHGDLWR2F3PDLRDLVK7MLDANCNFSM5WL344SQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>