Bug 14844 - brp-compress crashes in an unusual situation
Summary: brp-compress crashes in an unusual situation
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm-build
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
: 32225 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-30 00:12 UTC by Sam Varshavchik
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-07-30 00:13:46 UTC
Embargoed:


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

Description Sam Varshavchik 2000-07-30 00:12:55 UTC
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-30 00:13:44 UTC
Created attachment 1672 [details]
Spec file to demonstrate the problem.

Comment 2 Jeff Johnson 2000-07-30 01:42:04 UTC
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 15:25:13 UTC
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 16:54:10 UTC
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 14:40:11 UTC
*** 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.