How to set the build area for rpmbuild per-invocation

Question

I'm modifying an automated build, and want to tell rpmbuild to use a specific build area when invoking it.

This is similar to an existing question, but more specific.

• I don't want to run any of the build commands as the root user; the aim is only to have an RPM, not to install anything into the system.

• I don't want to require the user to change their dotfiles (e.g. $HOME/.rpmrc); the build should be self-contained and not affect the user's existing settings.

• I don't want to hard-code the location into the foo.spec file; that file should be useable as-is if the user wants to build in a different location.

• The --buildroot option is not what I need; that sets a pseudo-root filesystem for the make part of the build process, but I need to specify the “build area” for the entire RPM build process.

What I'm looking for is a hypothetical --build-area FOODIR option that can be given to the rpmbuild command, or an equivalent environment variable. It should thus affect just that single invocation of the command and cause it to use a specified user-writable location for its build area.

I've seen references to a _topdir macro that seems to be what I'm talking about, but it doesn't appear to be configurable per invocation.

It would be ideal if rpmbuild could set up its own environment in that location when it needs it, but I don't mind setting up the directories for that per build, since that can be automated as part of the build. The goal is to have that user-writable location exist only for the duration of the build run, and then clean up by deleting that entire location once the RPM file is generated.

Longplaying

Answer 1

It's not documented, but the _topdir macro determines the build area.

So you can set this per-invocation with rpmbuild --define "_topdir ${PWD}/foobar" ... to set the directory to whatever you want.

--define is the key to setting values for any macro, not just _topdir.

Hacienda

For the particular case of Linux kernel packaging, you can pass that option through RPMOPTS='define "foo bar"' on the make command line. – Layla

RPM is useless if it can't even do such a simple thing like self-contained build environments without having to resort to undocumented functionality. – Nadabb

@FUZxxl, it is documented, but a lot of people don't know were all the documentation is. fedoraproject.org/wiki/Packaging:RPMMacros?rd=Packaging/… clearly mentions _topdir, and gives it's default value, and makes not of how to set it with the "--define" all in one block (near the bottom of the page) – Samite

Answer 2

The --buildroot option is not what you are looking for. The name is a bit misleading as it is not changing the buildroot but instead is setting the root for the install phase of the build. RPM is basically doing a "make install" as part of the build and is then packing the results of this. The buildroot option allows you to do this install into for example /tmp/myinstallroot.

I recently had to integrate rpm package building into an automated build and had the same problem. What i did was to generate a custom .rpmmacros file with %topdir set appropriately. I then just temporarily changes HOME to the location of that custom .rpmmacros file.

"HOME=mytopdir rpmbuild ...".

Zirconia

Thanks, but requiring the user to change their dotfiles is not what I need. I'm trying to make the build process stand alone, so that a single command is sufficient to generate the RPM without having to make any other changes to one's user environment. – Longplaying

The trick is that i am not changing the the users environment. I generate an .rpmmacros file somewhere inside my build tree and then call rpmbuild with a modified $HOME. So yes, by temporarily changing $HOME i am modifying the users environment. Unfortunately i did found another way to do it. – Remediosremedy

Ah okay, you're saying that you use a .rpmmacros file which is not in the actual home directory. That's an interesting approach; it seems like an awful hack though. I hope there's a cleaner way. – Longplaying