Bug 260081 - Cannot use %{version} consistently for directory naming in rpmbuild
Cannot use %{version} consistently for directory naming in rpmbuild
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-28 09:23 EDT by Philip Ashmore
Modified: 2008-06-16 22:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-16 22:15:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Philip Ashmore 2007-08-28 09:23:58 EDT
+++ This bug was initially created as a clone of Bug #250951 +++

Description of problem:
rpmbuild -bp rpm.spec cannot find rpm-4.4.2.tar.gz

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

How reproducible:

Steps to Reproduce:
1. rpm -i rpm-4.4.2-46.fc7.src.rpm
2. cd ~/rpmbuild/rpm-4.4.2
3. rpmbuild -bp rpm.spec

The home directory (~) expands differently depending on your user name, so I've
put '~' everywhere the absolute path to my home directory occured.
Actual results:
error: File ~/rpmbuild/rpm-1.10.2/rpm-4.4.2.tar.gz: No such file or directory

Expected results:
rpmbuild should be looking for ~/rpmbuild/rpm-4.4.2/rpm-4.4.2.tar.gz

Additional info:
I've installed Mike A. Harris's rpmbuild-nonroot files - see 
It appears from looking at the rpm.spec file that it's using the version info
from rpm.spec line 74:
    Requires: popt = 1.10.2
- to locate the package source directory.

-- Additional comment from pnasrat@redhat.com on 2007-08-06 06:54 EST --
I don't recommend Mike Harris's rpmbuild-nonroot , try rpmdevtools from fedora
as using %{version} will get confused in packages like rpm that have packages
with multiple versions (it's the %package popt ... Version: not the line you
point out).

-- Additional comment from contact@philipashmore.com on 2007-08-07 21:02 EST --
I just tried rpmdevtools.
It seems to only allow you to install one source RPM package that gets unpacked
into the ~/rpmbuild/SOURCES directory - except for the .spec file - that goes
into the ~/rpmbuild/SPEC directory.

I tried to add the line
    %_sourcedir     %{_topdir}/SOURCES/%{name}-%{version}
to ~/.rpmmacros so that each installed source RPM would reside in it's own
directory, but the problem re-surfaced - it seems that having "%{version}"
anywhere in the %_sourcedir reproduces this problem - as you stated.

rpmbuild needs to copy the "version" variable to "rpm_version" or something
similiar the first time the "release" tag (barring a better option) is seen in
order to resolve this situation as it appears that the "version" variable is
being stepped on and so is unusable for this purpose.
This approach hinges around the issue that there seems to be no way to identify
a particular package as the "root" or "payload" package that these variables
should come from - the one the entire source RPM would hopefully have been named

Also is there a good reason for keeping the spec files in their own directory?

-- Additional comment from pmatilai@redhat.com on 2007-08-08 05:39 EST --
The only sane fix for this is to not try to bundle several packages with
different packages into one spec IMO. Popt living inside rpm is a historical
artifact mostly, one that's about to be removed for good by making popt into a
standalone package as it should: see bug #249352.

-- Additional comment from bugzilla@redhat.com on 2007-08-21 01:35 EST --
User pnasrat@redhat.com's account has been closed

-- Additional comment from pmatilai@redhat.com on 2007-08-22 02:33 EST --
Reassigning to owner after bugzilla made a mess, sorry about the noise...

-- Additional comment from pmatilai@redhat.com on 2007-08-28 02:16 EST --
This has now been "fixed" in rawhide by splitting out popt from the rpm package. 

Attempting to fix all the cases where separate packages with their own versions
are produced from a single spec with any arbitrary %_sourcedir isn't worth it.
Comment 1 Philip Ashmore 2007-08-28 09:26:45 EDT
My reason for re-raising this issue lies not with the practice of bundling
different packages in the same source RPM - it happens and the "spec" file
parser allows it.
It lies with the use of the "version" variable.
This should be copied to "rpm_version" when first encountered, or ideally from
the source RPM package name itself.
The reason - one can inspect the "rpmbuild" directory and see the same
name-version as is present in the source RPM package - that way you know what
version the sources relate to.

This issue most obviously surfaced with the "RPM" package itself but I was
looking for a pragmatic solution, not an ideal solution that doesn't relate to
the real world.
I think that being able to identify what source RPM version got installed into
the rpmbuild directory by looking at the directory name is definitely worth it.
Comment 2 Bug Zapper 2008-05-14 10:08:10 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Philip Ashmore 2008-05-14 10:33:08 EDT
I would suggest bumping this from Fedora 7 to Fedora 8 as it will continue to be
a problem as long as

1. spec files can contain more than one package
2. there isn't a way to specify the originating SRPM version in spec files
containing more than one package (I suggested a variable named "rpm_version").
Comment 4 Jeff Johnson 2008-05-18 15:01:38 EDT
As long as there are sub-packages, there is the potential for multiple
Version: tags. So there is no obvious choice for automagically choosing
a conventional value for %{version}

OTOH, its rather trivial to do
   %define my_one_true_version  1.2.3_whatever_you_want
    Version: %{my_one_true_version}

and then use %{my_one_true_version} instead of %{version}

Alternatively, if you simply _MUST_ use %{version}, the value is likely
to be the same as the last
    Version: 1.2.3_whatever_you_want
parsed in the spec file. You can arrange your sub-package stanzas so that the Version: you
want in %{version} appears last.
Comment 5 Bug Zapper 2008-06-16 22:15:06 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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