Red Hat Bugzilla – Bug 14844
brp-compress crashes in an unusual situation
Last modified: 2008-05-01 11:37:57 EDT
I just ran into a real weird problem building a huge package. The vendor tarball builds and installs about 40 man pages, uncompressed. I had a spec file that manually went in and compressed those manual pages, and I've explicitly listed the compressed manual pages in my %files. The manner that I compressed those man pages was such as the original uncompressed version wasn't removed, I was doing a gzip <$f >$f.gz, which is OK, because I explicitly listed all the .gz-s in my %files. This is a long story, that's the essence of it. Now, when the brp-compress finds a .gz man page, it does a gunzip on it, gunzip $f.gz, with the apparent intent to recompress the man page with a gzip-9. The problem here is that there's an uncompressed version already, and gunzip/gzip now prints an interactive prompt, it's asking whether or not you really want to overwrite an existing file. brp-compress does not expect gzip and gunzip to go interactive, and basically everything goes to hell from that point on. Try feeding the following spec file to rpm (create a dummy source code tarball for this one, it can be anything).
Created attachment 1672 [details] Spec file to demonstrate the problem.
If brp-compress is causing yo pain, then simply don't use it. There are many ways to do this, from the command line using --define, from macro configuration, or even from the spec file. Adding the following line to your spec file, for example, disables all Red Hat build root policies: %define __os_install_post /bin/true
Couldn't you add a flag to gzip (-f ?) in brp-compress to overwrite files without asking? Or maybe let the gzip output to be seen? I had the very same problem with the latest hylafax srpm, which does a very weird thing to compress man pages: ==== # compress the man pages for i in $(echo ${RPM_BUILD_ROOT}/usr/man/man?) do mkdir $i.gz cp -ad $i/* $i.gz/ gzip $i.gz/* cp -adu $i.gz/* $i/ done ====
Sure I can do all sorts of things, including fixing scripts, compiling sources, packaging binaries, and drinking Tequila :-) However, what I can't do, is distribute rpm any longer with a "one size fits all" mentaility reflected in rpm configuration. What works for Red Hat, may not work for Mandrake, or solaris or ppc-*. That basically means that policies used in producing packages need to be parameterized on a per-platform basis, and those policies (implemented in scripts) need to be added to rpm so that *everyone* is happy. I hope this helps.
*** Bug 32225 has been marked as a duplicate of this bug. ***