This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 281391 - rpmbuild -t creates bogus 'specfile' when fed with incorrect tarball
rpmbuild -t creates bogus 'specfile' when fed with incorrect tarball
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
: EasyFix
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-06 16:24 EDT by Lubomir Kundrak
Modified: 2008-04-04 04:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 04:59:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lubomir Kundrak 2007-09-06 16:24:21 EDT
Description of problem:

When you attempt to do an operation which involves unpacking a specfile from
tarball, and no specfile is present, rpmbuild creates a file whose name is
output from tar in place where would one expect the specfile (in case the
tarball was correct, of course).

Version-Release number of selected component (if applicable):

rpm-4.4.2.1-1.fc7

Steps to Reproduce:

$ rpmbuild -ta /dev/null
error: File /dev/null is smaller than 4 bytes
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: Group field must be present in package: (main package)
error: License field must be present in package: (main package)

Actual results:

$ ls ~/rpmbuild/SPECS/
tar: *.spec: Not found in archive

This file is definitely weirdly named and is not a spec file.

Expected results:

The same -- loud complains. Just without the additional file in SPECS directory.
Comment 1 Jeff Johnson 2007-09-06 20:41:53 EDT
Congratulations! You are only the 12th person to ever report this bug. That qualifies you as a bona
fide rpm hacker!

Meanwhile, don't do that is the answer. Ther better answer is ripping support for rpmbuild -ta foo.tar.gz,
but noone wants to hear that answer.
Comment 2 Lubomir Kundrak 2007-09-07 09:13:51 EDT
Jeff: If that sentence above the brilliant workaround is your usual response to
bug reports I finally understand the poor reputation you have.
Comment 3 R P Herrold 2007-09-08 12:15:25 EDT
hunh ... and who fed rpmbuild garbage, ignored the return code, and then complained?

Here I thought Unix like OS's provided power to users to push limits with new
combinations of approaches, rather than holding their hands, having guard rails,
and rolling over and dying.  I guess saying that an 'error' was detected **
seven times **, and returning a non-zero return code was not enough.

[herrold@couch ~]$ rpmbuild -ta /dev/null || echo "return code was not zero"
error: File /dev/null is smaller than 4 bytes
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: Group field must be present in package: (main package)
error: License field must be present in package: (main package)
return code was not zero
[herrold@couch ~]$

I wonder what will happen if I feed a chicken to rpmbuild ...
Comment 4 Panu Matilainen 2007-09-10 00:31:36 EDT
An error was detected alright, but creating files with weird names ('tar:
*.spec: Not found in archive') as a side-effect is ugly if nothing else.
Comment 5 Panu Matilainen 2008-04-04 04:59:12 EDT
Fixed upstream (finally).

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