Zlib

Option of yum repoquery:$ yum repoquery -l zlib-devel.x86_64/usr/include/zconf.h/usr/include/zlib.h/usr/lib64/libz.so/usr/lib64/pkgconfig/zlib.pc/usr/share/doc/zlib-devel/usr/share/doc/zlib-devel/algorithm.txt/usr/share/doc/zlib-devel/example.c/usr/share/man/man3/zlib.3.gzWe can use the same command for listing the contents of a non-installed package:$ yum repoquery -l iperf3.x86_64/usr/bin/iperf3/usr/lib/.build-id/usr/lib/.build-id/68/usr/lib/.build-id/68/c883ce2871cea4095c3d54b9b15ddc3f396146/usr/lib/.build-id/cd/usr/lib/.build-id/cd/978bb88ed41a61b505a70e4d24e8628f55bf79/usr/lib64/libiperf.so.0/usr/lib64/libiperf.so.0.0.0/usr/share/doc/iperf3/usr/share/doc/iperf3/LICENSE/usr/share/doc/iperf3/README.md/usr/share/doc/iperf3/RELEASE_NOTES/usr/share/man/man1/iperf3.1.gz/usr/share/man/man3/libiperf.3.gzTherefore, the yum repoquery command is an option for listing the contents of an installed or non-installed package in the YUM repository.5. Using repoqueryThe repoquery command is another alternative to get information about packages in YUM repositories. yum-utils package must be installed to use this command.We can use its -l option to list the files in a package. Let’s check the contents of the zlib-devel.x86_64 package:$ repoquery -l zlib-devel.x86_64/usr/include/zconf.h/usr/include/zlib.h/usr/lib64/libz.so/usr/lib64/pkgconfig/zlib.pc/usr/share/doc/zlib-devel/usr/share/doc/zlib-devel/algorithm.txt/usr/share/doc/zlib-devel/example.c/usr/share/man/man3/zlib.3.gzUsing repoquery with the -l option listed the contents of the zlib-devel.x86_64 package, as expected.Let’s check the contents of the other package, iperf3.x86_64, using repoquery:$ repoquery -l iperf3.x86_64/usr/bin/iperf3/usr/lib/.build-id/usr/lib/.build-id/4b/usr/lib/.build-id/4b/c883ce2871cea4095c3d54b9b15ddc3f396146/usr/lib/.build-id/c9/usr/lib/.build-id/c9/978bb88ed41a61b505a70e4d24e8628f55bf79/usr/lib64/libiperf.so.0/usr/lib64/libiperf.so.0.0.0/usr/share/doc/iperf3/usr/share/doc/iperf3/LICENSE/usr/share/doc/iperf3/README.md/usr/share/doc/iperf3/RELEASE_NOTES/usr/share/man/man1/iperf3.1.gz/usr/share/man/man3/libiperf.3.gzrepoquery also listed the contents of the non-installed package successfully. Therefore, the repoquery command is another option for listing the contents of an installed or non-installed package in the YUM repository.6. Using dnf repoqueryDNF (Dandified YUM) is the modern version of YUM with more robust and advanced features. It’s the default package management utility in the new versions of RPM-based Linux distros. The dnf command is the primary tool for the management of the packages. The yum command also exists in these distros for backward compatibility. In fact, yum is a symbolic link to dnf, for example in Red Hat 8.The usage of dnf repoquery command is similar to yum repoquery. It searches for packages matching a keyword:$ dnf repoquery zlib-devel.x86_64zlib-devel-0:1.2.11-33.el9.x86_64zlib-devel-0:1.2.11-34.el9.x86_64zlib-devel-0:1.2.11-35.el9.x86_64zlib-devel-0:1.2.11-36.el9.x86_64zlib-devel-0:1.2.11-39.el9.x86_64We can get the contents of a package by using the -l option of dnf repoquery:$ dnf repoquery -l zlib-devel.x86_64/usr/include/zconf.h/usr/include/zlib.h/usr/lib64/libz.so/usr/lib64/pkgconfig/zlib.pc/usr/share/doc/zlib-devel/usr/share/doc/zlib-devel/algorithm.txt/usr/share/doc/zlib-devel/example.c/usr/share/man/man3/zlib.3.gzWe can use the same command for listing the contents of a non-installed package:$ dnf repoquery -l iperf3.x86_64/usr/bin/iperf3/usr/lib/.build-id/usr/lib/.build-id/68/usr/lib/.build-id/68/c883ce2871cea4095c3d54b9b15ddc3f396146/usr/lib/.build-id/cd/usr/lib/.build-id/cd/978bb88ed41a61b505a70e4d24e8628f55bf79/usr/lib64/libiperf.so.0/usr/lib64/libiperf.so.0.0.0/usr/share/doc/iperf3/usr/share/doc/iperf3/LICENSE/usr/share/doc/iperf3/README.md/usr/share/doc/iperf3/RELEASE_NOTES/usr/share/man/man1/iperf3.1.gz/usr/share/man/man3/libiperf.3.gzTherefore, we can use the dnf repoquery command to list the contents of an installed or non-installed package in the DNF repository.7. ConclusionIn this article, we learned how to list the contents of a package when we don’t have the RPM package file.Firstly, we learned that we can use the rpm command to list the contents of an installed package. Then, we examined the yum repoquery, repoquery and dnf repoquery commands. We saw that we

1. OverviewRPM (Red Hat Package Manager) is the package management system used in several Linux distributions, such as Red Hat, Fedora, and openSUSE.Sometimes, we may need to list the files in an RPM package. We can list the contents of a package by passing the name of the package file as an argument to the rpm command together with the -q and -l options. However, the RPM package file may not always be available.In this tutorial, we’ll discuss how to list the contents of an RPM package when we don’t have the package file.2. Sample PackagesWe’ll inspect two packages in the package repository. They’re zlib-devel.x86_64 and iperf3.x86_64 packages. Let’s verify their existence in the repository:$ dnf list installed | grep zlib-devel.x86_64zlib-devel.x86_64 1.2.11-31.el9 @appstream$ dnf list available | grep iperf3.x86_64iperf3.x86_64 3.9-9.el9 @appstreamThe dnf list installed command lists the installed packages. On the other hand, the dnf list available command lists the available packages, i.e., non-installed ones.We used the grep command to filter the output of dnf list. We see that zlib-devel.x86_64 is an already installed package, but the other one, iperf3.x86_64, isn’t installed.We can check an already installed package’s content using rpm even if we don’t have the RPM package file. The name of the package instead of the RPM package file must be passed to the rpm command:$ rpm -ql zlib-devel.x86_64/usr/include/zconf.h/usr/include/zlib.h/usr/lib64/libz.so/usr/lib64/pkgconfig/zlib.pc/usr/share/doc/zlib-devel/usr/share/doc/zlib-devel/algorithm.txt/usr/share/doc/zlib-devel/example.c/usr/share/man/man3/zlib.3.gzWe listed the contents of zlib-devel.x86_64 successfully. The -q option of rpm is for querying a package. The -l option is for listing the contents of a package.Let’s try to list the contents of the non-installed package, iperf3.x86_64, using rpm:$ rpm -ql iperf3.x86_64Package iperf3.x86_64 is not installedTherefore, we can’t list the contents of a non-installed package using rpm.4. Using yum repoqueryYUM (Yellowdog Updater, Modified) is a package management utility based on the RPM Package Manager. The yum command is the primary tool for the management of the packages.The yum repoquery command searches for packages matching a keyword:$ yum repoquery zlib-devel.x86_64zlib-devel-0:1.2.11-33.el9.x86_64zlib-devel-0:1.2.11-34.el9.x86_64zlib-devel-0:1.2.11-35.el9.x86_64zlib-devel-0:1.2.11-36.el9.x86_64zlib-devel-0:1.2.11-39.el9.x86_64There are five different versions of the zlib-devel.x86_64 library in our system according to the output of yum repoquery zlib-devel.x86_64.We can get the contents of a package by using the -l

That can, among other things, take advantage of CPU vectorisation.$ wget -c -O arc \ chmod +x arcfor i in {1..25}; do ./arc -overwrite unarchive hadoop.zipdoneThe above completed in 100.975 seconds.Next I'll benchmark version 9.20.1 of the Debian-patched 7-Zip utility.for i in {1..25}; do 7z x -bd -y -oworking/ hadoop.zip 1>/dev/nulldoneThe above completed in 72.2 seconds.Version 9.20.1 of 7-Zip above was released in 2010. I'll fetch a more recent Debian release of 7-Zip. The following will install version 16.02 which was released in mid-2016.$ wget -c sudo dpkg -i p7zip_16.02+dfsg-7_amd64.debI'll then run the 7-Zip benchmark again.The above completed in 58.05 seconds.Next I'll compile zlib "next generation". This zlib fork is also being worked on by Mark Adler and has several performance-related patches produced by firms such as Cloudflare and Intel. The past two years has seen over 70 commits from Sebastian Pop who has a long CV with roles at firms such as AWS, Samsung R&D, Qualcomm, AMD, IBM as well as the FSF and the LLVM project.The following was run using GCC version 5.4.0.$ git clone ~/zlib-ng$ cd ~/zlib-ng$ mkdir -p out$ CFLAGS="-O4 -m64 -DZLIB_COMPAT -DWITH_GZFILEOP -DHAVE_HIDDEN -DHAVE_BUILTIN_CTZL -DMEDIUM_STRATEGY -DX86_64 -DX86_NOCHECK_SSE2 -DUNALIGNED_OK -DUNROLL_LESS -DX86_CPUID -DX86_SSE2_FILL_WINDOW -DX86_SSE4_2_CRC_HASH -DX86_PCLMULQDQ_CRC -DX86_QUICK_STRATEGY" \ ./configure \ --prefix=./out \ --zlib-compat$ make$ make installPython is dynamically linked to zlib so I can use the above as a drop-in replacement for its unzip functionality.$ objdump --dynamic-syms /usr/bin/python2.7 | grep ZLIB0000000000000000 DF *UND* 0000000000000000 ZLIB_1.2.0 inflateCopyfor i in {1..25}; do LD_PRELOAD=/home/mark/zlib-ng/out/lib/libz.so.1.2.11.zlib-ng \ /usr/bin/python2.7 \ -m zipfile \ -e hadoop.zip \ working/doneThe above completed in 48.9 seconds.Finally, I'll compile my own version of Info-ZIP's unzip utility and see if I can find any performance improvements over the Debian-patched release.$ git clone cd unzip$ mkdir -p out/bin$ export CFLAGS="-O4 -m64 -DZLIB_COMPAT -DWITH_GZFILEOP -DHAVE_HIDDEN -DHAVE_BUILTIN_CTZL -DMEDIUM_STRATEGY -DX86_64 -DX86_NOCHECK_SSE2 -DUNALIGNED_OK -DUNROLL_LESS -DX86_CPUID

Is both faster (by up to 40%) and smaller (14 kB minified) than pako, and it contains a variety of innovations that make it excellent for both performance and compression ratio. However, the developer made a variety of tiny mistakes and inefficient design choices that make it imperfect. Moreover, it does not support GZIP or Zlib data directly; one must remove the headers manually to use UZIP.js.So what makes fflate different? It takes the brilliant innovations of UZIP.js and optimizes them while adding direct support for GZIP and Zlib data. And unlike all of the above libraries, it uses ES Modules to allow for partial builds through tree shaking, meaning that it can rival even tiny-inflate in size while maintaining excellent performance. The end result is a library that, in total, weighs 8kB minified for the core build (3kB for decompression only and 5kB for compression only), is about 15% faster than UZIP.js or up to 60% faster than pako, and achieves the same or better compression ratio than the rest.Before you decide that fflate is the end-all compression library, you should note that JavaScript simply cannot rival the performance of a native program. If you're only using Node.js, it's probably better to use the native Zlib bindings, which tend to offer the best performance. Though note that even against Zlib, fflate is only around 30% slower in decompression and 10% slower in compression, and can still achieve better compression ratios!What about CompressionStream?Like fflate, the Compression Streams API provides DEFLATE, GZIP, and Zlib compression and decompression support. It's a good option if you'd like to compress or decompress data without installing any third-party libraries, and it wraps native Zlib bindings to achieve better performance than what most JavaScript programs can achieve.However, browsers do not offer any native non-streaming compression API,