10

Is there a tool that allows to install the dependecies of an RPM .spec into an isolated environment? I won't install such dependencies globally on the system and I am not able to do so since I have not root privileges.

The reason

I want to build a package A which depends on a newer version of B (which cannot be installed globally on the system).

I like to build the newer version of B and let the build tool install B's -devel it into an isolated environment to provide all necessary files for the build of A.

Solutions

  • Are there any tools to do this?
  • If not, what should I take care of when trying to do this with say chroot?
  • Would this be a bad practice?
try-catch-finally
  • 204
  • 4
  • 15

3 Answers3

8

Yes, the tool is called mock and it's in EPEL.

Typical usage:

rpmbuild -bs mypackage.spec
mock -r epel-6-x86_64 mypackage-0.1-1.src.rpm

This is actually the preferred way to build RPMs, precisely because it isolates the process from the system so that unexpected dependencies don't get pulled in.

You can modify the files in /etc/mock to have it pull in your own packages, private repo, etc., or check the docs for info on how to add packages to the mock chroot environment manually.

Note that users should be added to the mock group to be allowed to use mock.

Not coincidentally, the koji build server that Red Hat uses calls mock to build each individual package. If you have to build a lot of packages all the time, it may be worth looking into setting up a koji build server.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
3

I think attempting to build packages on production hosts is bad practice and attempting to do it without root privileges is more complicated than bringing up your own build machines. What I normally do is the following.

  1. Install VirtualBox or similar tool on your desktop/laptop
  2. Create 32/64 VMs of the OS you use in production
  3. Install the usually mock, rpmbuild, etc tools
  4. Create the RPMs for the package and any additional deps for both archs on yours VMs
  5. After testing push the RPMs into your internal repo for distribution to your servers
  6. Test again to make sure the proper dependencies are being pulled in
  7. Release via your config management.
Ramin
  • 336
  • 1
  • 5
  • This will work. How is it better than using mock? I would think mock would be easier, but I suspect that either way pretty much the same thing is happening. – emory Jan 05 '13 at 01:28
  • I've got no problem with mock and I believe that nearly all "how to make an rpm" docs have you install it. However without root access I'm not sure how the OP is going to add their account to the mock group, install mock, and so forth. Also having clean build VMs helps avoid odd dependencies from unintentionally being added to packages. – Ramin Jan 05 '13 at 22:06
  • Excellent point. I failed to consider that. With that in mind, I think this is the correct answer. – emory Jan 06 '13 at 00:30
  • @emory based on your feedback I clarified why I think build VMs are better solution overall which I think makes a better answer. Thanks for prodding me. :-) – Ramin Jan 06 '13 at 01:46
  • @Ramin in my situation (at work) I am only *user*. The system is a dedicated build system and well, if all developers on that host would have root privileges, that box would not boot after 1 week. ;) So using a tool like Mock is exactly the right thing to use! Setting up VMs is also a good idea if it can be wel automated. I think [Vagrant](http://www.vagrantup.com/) (I havn't tested it yet) is just the right tool for that. – try-catch-finally Jan 07 '13 at 18:25
0

You want to use mock. It allows you to build rpms in a chroot

https://fedorahosted.org/mock/

Mike
  • 22,310
  • 7
  • 56
  • 79