Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This creates a real backporting problem for people like me who publish internal backports of leading edge components, or who try to publish backports from Fedora to EPEL. It breaks the "mock" toolkit for compiling RPMs under various new operating systems, and it breaks the bility to run "rpmbuild" on a Fedora 31 SRPM.
Whether I consider zstd to be an extraneous and entirely unnecessary optimization, it's in place. There are support problems of CentOS taking on supporting an enhanced RPM software to resolve this. Is there any interest in taking this on for centosplus?
On Sat, Nov 2, 2019 at 4:47 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This creates a real backporting problem for people like me who publish internal backports of leading edge components, or who try to publish backports from Fedora to EPEL. It breaks the "mock" toolkit for compiling RPMs under various new operating systems, and it breaks the bility to run "rpmbuild" on a Fedora 31 SRPM.
Whether I consider zstd to be an extraneous and entirely unnecessary optimization, it's in place. There are support problems of CentOS taking on supporting an enhanced RPM software to resolve this. Is there any interest in taking this on for centosplus?
Feel free to make a case for Red Hat to backport support for zstd to RHEL 7. They've done it in the past when Fedora introduced the switch to xz (RHEL didn't have it at the time either!). RPM in RHEL 8.2 will have zstd support. If you have a Red Hat customer account, feel free to make a case for it to be made available as a z-stream update to 8.1.
On Sat, Nov 2, 2019 at 5:05 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Nov 2, 2019 at 4:47 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This creates a real backporting problem for people like me who publish internal backports of leading edge components, or who try to publish backports from Fedora to EPEL. It breaks the "mock" toolkit for compiling RPMs under various new operating systems, and it breaks the bility to run "rpmbuild" on a Fedora 31 SRPM.
Whether I consider zstd to be an extraneous and entirely unnecessary optimization, it's in place. There are support problems of CentOS taking on supporting an enhanced RPM software to resolve this. Is there any interest in taking this on for centosplus?
Feel free to make a case for Red Hat to backport support for zstd to RHEL 7. They've done it in the past when Fedora introduced the switch to xz (RHEL didn't have it at the time either!). RPM in RHEL 8.2 will have zstd support. If you have a Red Hat customer account, feel free to make a case for it to be made available as a z-stream update to 8.1.
I'd be happy with having it in RHEL 8.2 and CentOS 8.2. I'm somewhat skeptical about a projected release date for this feature, since this would touch RPM, which is in the new and suppossedly hyperstable "BaseOS" channel.
I've tried to report it as a feature request with my Red Hat Linux Server license. As it seems to turn out, their main web page customer support page doesn't have any apparent links to to the Bugzilla, it just accepts described problems to try and guess, in this case irrelevantly, about what Wiki might have information. But the Bugzilla is still available, I submitted it at https://bugzilla.redhat.com/show_bug.cgi?id=1768147
On Sat, Nov 2, 2019 at 9:03 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Sat, Nov 2, 2019 at 5:05 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Nov 2, 2019 at 4:47 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This creates a real backporting problem for people like me who publish internal backports of leading edge components, or who try to publish backports from Fedora to EPEL. It breaks the "mock" toolkit for compiling RPMs under various new operating systems, and it breaks the bility to run "rpmbuild" on a Fedora 31 SRPM.
Whether I consider zstd to be an extraneous and entirely unnecessary optimization, it's in place. There are support problems of CentOS taking on supporting an enhanced RPM software to resolve this. Is there any interest in taking this on for centosplus?
Feel free to make a case for Red Hat to backport support for zstd to RHEL 7. They've done it in the past when Fedora introduced the switch to xz (RHEL didn't have it at the time either!). RPM in RHEL 8.2 will have zstd support. If you have a Red Hat customer account, feel free to make a case for it to be made available as a z-stream update to 8.1.
I'd be happy with having it in RHEL 8.2 and CentOS 8.2. I'm somewhat skeptical about a projected release date for this feature, since this would touch RPM, which is in the new and suppossedly hyperstable "BaseOS" channel.
Adding functionality is always easy. It's removing stuff that's hard.
I've tried to report it as a feature request with my Red Hat Linux Server license. As it seems to turn out, their main web page customer support page doesn't have any apparent links to to the Bugzilla, it just accepts described problems to try and guess, in this case irrelevantly, about what Wiki might have information. But the Bugzilla is still available, I submitted it at https://bugzilla.redhat.com/show_bug.cgi?id=1768147
That's essentially a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1715799
On Sat, Nov 2, 2019 at 9:34 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Nov 2, 2019 at 9:03 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
I've tried to report it as a feature request with my Red Hat Linux Server license. As it seems to turn out, their main web page customer support page doesn't have any apparent links to to the Bugzilla, it just accepts described problems to try and guess, in this case irrelevantly, about what Wiki might have information. But the Bugzilla is still available, I submitted it at https://bugzilla.redhat.com/show_bug.cgi?id=1768147
That's essentially a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1715799
Thank you for the pointer. It's a duplicate.
On Sun, Nov 3, 2019 at 12:40 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Sat, Nov 2, 2019 at 9:34 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Nov 2, 2019 at 9:03 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
I've tried to report it as a feature request with my Red Hat Linux Server license. As it seems to turn out, their main web page customer support page doesn't have any apparent links to to the Bugzilla, it just accepts described problems to try and guess, in this case irrelevantly, about what Wiki might have information. But the Bugzilla is still available, I submitted it at https://bugzilla.redhat.com/show_bug.cgi?id=1768147
That's essentially a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1715799
Thank you for the pointer. It's a duplicate.
And... there is apparently a workaround now for doing mock compilation, though it doesn't solve the inability to use "rpm -i" or "rpm2cpio" on such compresed files. Recent versions of "mock" involve the use of bootstrap images with "podman".
* yum install podman * Add these lines to /etc/mock/templates/fedoa-31.tpl * * config_opts['use_bootstrap_container'] = True * * config_opts['use_bootstrap_images'] = True
On Sat, Nov 02, 2019 at 04:47:01PM -0400, Nico Kadel-Garcia wrote:
Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This is not the case.
Fedora switched binary rpms to use zstd. src.rpms are still using xz? (or perhaps gzip, but definitely not zstd).
Fedora src.rpms should unpack fine on el 6/7/8.
kevin
On Sat, Nov 2, 2019 at 6:34 PM Kevin Fenzi kevin@scrye.com wrote:
On Sat, Nov 02, 2019 at 04:47:01PM -0400, Nico Kadel-Garcia wrote:
Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This is not the case.
Fedora switched binary rpms to use zstd. src.rpms are still using xz? (or perhaps gzip, but definitely not zstd).
Source RPMs use gzip.
Fedora src.rpms should unpack fine on el 6/7/8.
I think the concern was about binary RPMs. After all, Mock cannot build Fedora build roots on any Enterprise Linux release now, at least not until EL8.2 (if things go as currently planned). This means Koji builders can't run on CentOS/RHEL to build for Fedora, since Koji doesn't support any bootstrap mode (bootstrap chroot or bootstrap container).
On Sat, Nov 2, 2019 at 7:18 PM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Nov 2, 2019 at 6:34 PM Kevin Fenzi kevin@scrye.com wrote:
On Sat, Nov 02, 2019 at 04:47:01PM -0400, Nico Kadel-Garcia wrote:
Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This is not the case.
Fedora switched binary rpms to use zstd. src.rpms are still using xz? (or perhaps gzip, but definitely not zstd).
Source RPMs use gzip.
Checking them again, they're using "xz" for the SRPMs for Fedora 31, which introduced its own set of fractures when it was introduced on top of gz support back in.... 2007 ?
Fedora src.rpms should unpack fine on el 6/7/8.
I think the concern was about binary RPMs. After all, Mock cannot build Fedora build roots on any Enterprise Linux release now, at least not until EL8.2 (if things go as currently planned). This means Koji builders can't run on CentOS/RHEL to build for Fedora, since Koji doesn't support any bootstrap mode (bootstrap chroot or bootstrap container).
Even the "use_bootstrap_container" option doesn't work for mock, I didn't expect it to, but thought I'd double check.
On 3/11/19 3:01 PM, Nico Kadel-Garcia wrote:
Even the "use_bootstrap_container" option doesn't work for mock, I didn't expect it to, but thought I'd double check.
I suspect that you could get it to work if you can specify the F30 repos for the bootstrap container (this is assuming that F30 repos still use the older compression but has support for the newer compression). I'm not sure if mock even has an option to do that and would have to dig through the source to find out, though.
Peter
On Sat, Nov 2, 2019 at 6:34 PM Kevin Fenzi kevin@scrye.com wrote:
On Sat, Nov 02, 2019 at 04:47:01PM -0400, Nico Kadel-Garcia wrote:
Fedora 31 elected to use a new compression algorithm, "zstd", to compress RPM's. The result of this unnecessary optimization is that even commercially supported and long-term-support operating systems, like RHEL 7 and 8, and CentOS 7 and 8, cannot deconstruct leading edge Fedora SRPM's, especially the bleeding edge ones from rawhide.
This is not the case.
Fedora switched binary rpms to use zstd. src.rpms are still using xz? (or perhaps gzip, but definitely not zstd).
Fedora src.rpms should unpack fine on el 6/7/8.
What the *devil*?
(Downloading again and taking apart)
Oh, boy. Yes, the SRPMs succeed. The RPMs fail, which breaks the "mock" based compilation of Fedora 31 and rawhide components.
I was confused, and will update my fresh bugzilla.
-
Kevin Fenzi -
Neal Gompa -
Nico Kadel-Garcia -
Peter