Bug 124364 - [PATCH] rpmbuild sets macros incorrectly
[PATCH] rpmbuild sets macros incorrectly
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
patch
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-25 19:05 EDT by Leonard den Ottolander
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-21 10:00:18 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)
Fixes the macros %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} (1.59 KB, patch)
2004-06-20 19:56 EDT, Leonard den Ottolander
no flags Details | Diff
Fixes the macros %{version}, %{release}, %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} (3.37 KB, patch)
2004-06-21 07:34 EDT, Leonard den Ottolander
no flags Details | Diff
Leaves all macros intact if not the initial package (3.52 KB, patch)
2004-06-24 10:17 EDT, Leonard den Ottolander
no flags Details | Diff

  None (edit)
Description Leonard den Ottolander 2004-05-25 19:05:48 EDT
rpm-4.2.1-0.30, popt-1.8.1-0.30

rpmbuild -bp rpm.spec fails:
error: File /data/rpmbuild-fc1/rpm-1.8.1/rpm-4.2.1.tar.gz: No such
file or directory

It looks like the last "Version:" (popt's) is being used in the path
expansion for %setup.
Comment 1 Jeff Johnson 2004-05-25 19:23:55 EDT
Built for me way back when. Check your configuration,
the value for %_sourcedir probably has a macro within.

Try
   rpm --showrc | grep sourcedir
to see what the setting is.
Comment 2 Leonard den Ottolander 2004-05-25 19:41:25 EDT
I'm using Mike Harris' rpmbuild-nonroot setup (except for his no archs
hack). Rebuilding as root (without these hacks) works fine, indeed.

$ rpm --showrc | grep sourcedir
  RPM_SOURCE_DIR="%{u2p:%{_sourcedir}}"
RPM_SOURCE_DIR="%{_sourcedir}"
-14: _sourcedir %{_topdir}/%{name}-%{version}
-14: _specdir   %{_sourcedir}

It looks as if %{version} is being interpreted wrong. Now why is that?
Comment 3 Jeff Johnson 2004-05-26 08:51:43 EDT
You have a configuration problem, fix (or get mharris to fix)
the configuration.
Comment 4 Mike A. Harris 2004-05-26 11:56:09 EDT
Leonard:

My rpm configuration does not allow the usage of rpm to build rpm
packages from tarballs.  The reason for this, is that some of the
directories that rpm requires do not exist until you run rpm to
create them.  When you install a src.rpm package using my rpm
configuration, all of the directories are automatically created
by rpm if they don't exist.  However, when using a tarball, this
does not happen, and so using the tarball build options are not
possible with my rpm configuration.

There are 4 choices for handling this problem that I can think of:

1) Don't use rpm tarball building options (my personal choice)

2) Modify my rpm configuration with some custom trickery to get it
   to create the needed directories, possibly by using %() tricks.
   If you do this and get it working, please send me a unified diff
   to have a look at.

3) Write a patch to rpm that makes it create the missing directories,
   however it is debateable wether it should be rpm's job to create
   the dirs or not, so such a patch may or may not be acceptable to
   Jeff.

4) Don't use my rpm configuration.   ;o)


My solution of #1 above works well enough for me that I don't plan
on solving the tarball building problem myself, but feel free to
whip up a solution using my configuration if you like.

Hope this helps,
TTYL
Comment 5 Leonard den Ottolander 2004-05-26 12:54:40 EDT
Not entirely sure what you mean with "tarball building options" (the
-b switches?), but rpm --rebuild rpm-<version>.src.rpm fails just as
well with the same error. I usually do an rpm -iv <pkg> and then a rpm
-bb <pkg>.spec.

The problem seems to be that %{version} is set to the value of the
last "Version:" tag in the spec file. In this case the version of
popt. So instead of looking in %{_topdir}/rpm-4.2.1 rpm looks in
%{_topdir}/rpm-1.8.1, ie substituting the wrong value for %{version}.

What macro could I use to get the first "Version:" tag's value?

Maybe we should have this discussion on the fedora-devel list?
Comment 6 Michael Schwendt 2004-05-26 13:02:03 EDT
Mike, Leonard, this is unrelated to building from tarballs (rpmbuild
-tb foo.tgz).

For this particular package, just drop %{version} from your
%_sourcedir definition.
Comment 7 Leonard den Ottolander 2004-06-20 19:56:09 EDT
Created attachment 101281 [details]
Fixes the macros %{PACKAGE_VERSION} and %{PACKAGE_RELEASE}

This patch fixes the backward compatibility macros %{PACKAGE_VERSION} and
%{PACKAGE_RELEASE} which with this patch now return correct values.

This means
%_sourcedir	%{_topdir}/%{name}-%{PACKAGE_VERSION}
works correctly with this patch.

Sadly applying a similar change (passing initialPackage) to headerAddEntry() is
much more intrusive as that function is called much more often.

If I would cook up that patch would it be considered?
Comment 8 Leonard den Ottolander 2004-06-21 07:31:28 EDT
Attaching a complete patch that fixes this issue by setting the macros
%{version}, %{release}, %{PACKAGE_VERSION} and
%{PACKAGE_RELEASE} conditionally.

Only question remaining is if there are other macros that should only
be set conditionally.
Comment 9 Leonard den Ottolander 2004-06-21 07:34:46 EDT
Created attachment 101290 [details]
Fixes the macros %{version}, %{release}, %{PACKAGE_VERSION} and %{PACKAGE_RELEASE}

This patch fixes the macros %{version} and %{release} as well as the backward
compatibility macros %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} which with this
patch now return correct values.

This means both
%_sourcedir	%{_topdir}/%{name}-%{version}
and
%_sourcedir	%{_topdir}/%{name}-%{PACKAGE_VERSION}
work correctly with this patch.
Comment 10 Jeff Johnson 2004-06-21 10:00:18 EDT
Patch looks like correct.

I see no reason to preserve the very ancient (and UGLY)
PACKAGE_VERSION and PACKAGE_RELEASE tags that were in
use in the original macro implementation circa 1998.

Having two side-effect macros (i.e. a macro named foo
set when a Foo: tag is parsed in a spec file) is
already rather mysterious to most users, and there
is the additional confusion from having 2 ways to do
the same operation that will lead to questions about
which is the correct procedure.

If anything, PACKAGE_VERSION and PACKAGE_RELEASE should be
entirely removed. But the removal is impossible because that
would break rebuilds of ancient packages.

And there are deeper problems with rebuild from tarballs creating
directories, stderr will be splatted onto the file system
if the tarball does not contain a *.spec file, and none
of the macros are known when the tarball is opened. That
(i.e. build from tarball) too needs to be removed from rpm.
Comment 11 Leonard den Ottolander 2004-06-21 10:11:08 EDT
If the patch looks correct why do you close this bug WONTFIX?

Note that the original patch only fixed the compatibility macros, but
the new patch also fixes the macros %{version} and %{release}.
Comment 12 Leonard den Ottolander 2004-06-22 03:40:32 EDT
> And there are deeper problems with rebuild from tarballs

I never spoke of building from tarballs. This bug report has nothing
to do with builing from tarballs, IT'S ABOUT MACROS RETURNING WRONG
VALUES so one can't setup an alternative build root correctly.

I don't care if you want to obsolete PACKAGE_VERSION and
PACKAGE_RELEASE; but as long as they are around they should return a
correct value.

More importantly this patch fixes the macros %{version} and
%{release}, which is fixing the issue I reported in the first place
(see comment #2).
Comment 13 Leonard den Ottolander 2004-06-24 10:17:01 EDT
Created attachment 101373 [details]
Leaves all macros intact if not the initial package

Leaves all (current and backward compatibility) macros intact if a package
other than the initial package in the SPEC file is parsed.

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