querying behavior of built in c-macros. (was definition of %doc)

Edward Peschko horos11 at gmail.com
Fri Mar 5 04:04:18 UTC 2010

(ps - looking at it a little bit closer, I see that the reason why
this isn't working is because %_docdir is relying on %_defaultdocdir,
which is relying on %_usr, and if I override %_usr, then %doc snaps

Which sort of brings on the following question - how do you see the
behavior of the underlying c-macros, without actually going into  the
c code and plowing around? Is there a doc somewhere?

And am I going to get in trouble re-defining %_usr if all I want to do
is make relocatable packages? When I redefined %_var, it caused all
sorts of issues with rpmbuild itself because the rpmbuild process uses
%_var for various things - and i'm afraid that redefining %_usr is
going to cause similar issues.

And all in all, why can't you simply set '%_prefix' to something and
have everything in rpmbuild snap to? Is that something that rpmbuild
is working towards?


On Thu, Mar 4, 2010 at 6:34 PM, Edward Peschko <horos11 at gmail.com> wrote:
> Ok all,
> After some investigation and some rpmbuild assistance (thanks jeff), I
> take it that there are certain macros that cannot be overridden, as
> they are compiled into rpmbuild (%prep, %setup, etc).
> I was wondering if %doc fell under the same category - for example, I
> see in %files tags for different rpms that there are lines like:
>    %doc <filename>
> which then gets expanded behind the scenes to paths like
> /usr/share/doc/
> You would think that this would use %_docdir under the covers, so that
> you could use it in a relocatable way (ie: for packages not rooted in
> '/'.) However, it seems to be hardcoded somewhere, so that I get a
> fully relocatable file EXCEPT for any rpms that use this macro.
> So - is this just a bug?  Or is %doc just using another macro that I'm
> not aware of? Or can you actually see and override this macro and I
> just haven't hit on how to do so?
> Thanks much,
> Ed
> (ps - btw I'm working off of a binary installation of rpmbuild -
> where's a pointer to the latest source version, or better yet, a git
> repository?)

More information about the Rpm-list mailing list