Bug 32124 - /usr/lib/rpm/macros:___build_post has martian value
/usr/lib/rpm/macros:___build_post has martian value
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-18 06:52 EST by j. alan eldridge
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-18 08:59:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description j. alan eldridge 2001-03-18 06:52:59 EST
Re /usr/lib/rpm/macros from rpm-4.0:

we see:
%___build_post	exit 0
%__os_install_post	%{___build_post}

now for ix86, __os_install_post gets redefined, so it runs the brp-*
scripts that compress man pages and do other forms of chaos.

*BUT* for arch == noarch, *like when you're building scripts*, then we can
run into a problem.

I use this %install section in my spec files:

---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<---
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT
%makeinstall

# __os_install_post is implicitly expanded after the
# %install section... do it now, and then disable it,
# so all work is done before building manifest.

%{?__os_install_post}
%define __os_install_post %{nil}

# build the file list automagically into %{manifest}

cd $RPM_BUILD_ROOT
rm -f %{manifest}
find . -type d \
        | sed '1,2d;s,^\.,\%attr(-\,root\,root) \%dir ,' >> %{manifest}
find . -type f \
        | sed 's,^\.,\%attr(-\,root\,root) ,' >> %{manifest}
find . -type l \
        | sed 's,^\.,\%attr(-\,root\,root) ,' >> %{manifest}
---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<-snip---8<---

So, for ix86, the most common arch, everything works just peachy. So I'm
whipping up a .spec for a shell script package, and later on, when I do the
"%files -f %{manifest}" bit, I'm dog food. Hmmm....

Aha! __os_install_post ==> ___build_post ==> exit 0! The macro expansion
terminates my install procedure before I've build my nice little automatic
file list.

Jeff, is there a reason why that macro is "exit 0" rather than just %{nil}.
I can't think of one of the top of my head, other than to make life
exciting for people like me. Do you think it could be changed to %{nil}?
Comment 1 Jeff Johnson 2001-03-18 08:59:39 EST
Um, what's "dog food"? Can you describe your problem more precisely?

Meanwhile, the exit 0 is present to insure that the exit code isn't set by the
last failed command, as in a construct like

	[ -f /tmp/foo ] && do domething

If the test fails, the exit code will be set by the test, not the "do
something".
Comment 2 j. alan eldridge 2001-03-18 09:57:04 EST
jeff,

By "I'm dog food,"  I mean that my %install section exits on the expansion
%{?__os_install_post}, so it never proceeds to build the file list.

The idea is, I need to run whatever would normally be run after everything in
the %install section, and then *continue*, and do the rest of my thing, and then
*not* run it when it would normally be run implicitly. IOW, I'm taking the
invisible part of the install and making it visible by executing it early.

These implicitly executed macros are a PITA, partly because there's no
documentation on who runs what when, although where and why is pretty clear from
inspection. I'm going to close this because it's not as much a bug as a really
annoying peculiararity that can be argued either way. I'm just uncoditionally
defining ___build_post to nil in my spec file skeleton. It won't hurt anything
that I can tell. IOW:
%define ___build_install %{nil}
%{?__os_install_post}
%define __os_install_post %{nil}

BTW take this bit to email if you would: What happens if a variable that has
been %undef'd out of existence gets deferenced? And, is there any way to say
"please undef this thing until the definition stack for it runs out"?  Guessing
(1) a bad thing and (2) nope.

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