Bug 281391

Summary: rpmbuild -t creates bogus 'specfile' when fed with incorrect tarball
Product: [Fedora] Fedora Reporter: Lubomir Kundrak <lkundrak>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: rawhideCC: mmahut, pnasrat
Target Milestone: ---Keywords: EasyFix
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-04 08:59:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lubomir Kundrak 2007-09-06 20:24:21 UTC
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-07 00:41:53 UTC
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 13:13:51 UTC
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 16:15:25 UTC
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 04:31:36 UTC
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 08:59:12 UTC
Fixed upstream (finally).