Bug 14844 - brp-compress crashes in an unusual situation
brp-compress crashes in an unusual situation
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rpm-build (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
: 32225 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-07-29 20:12 EDT by Sam Varshavchik
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-29 20:13:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Spec file to demonstrate the problem. (671 bytes, text/plain)
2000-07-29 20:13 EDT, Sam Varshavchik
no flags Details

  None (edit)
Description Sam Varshavchik 2000-07-29 20:12:55 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).
Comment 1 Sam Varshavchik 2000-07-29 20:13:44 EDT
Created attachment 1672 [details]
Spec file to demonstrate the problem.
Comment 2 Jeff Johnson 2000-07-29 21:42:04 EDT
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
Comment 3 giulioo 2000-07-30 11:25:13 EDT
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
====

Comment 4 Jeff Johnson 2000-07-30 12:54:10 EDT
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.
Comment 5 Jeff Johnson 2001-03-19 09:40:11 EST
*** Bug 32225 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.