Contents

Building anaconda

Building and packaging anaconda is not overly difficult, but it does involve a lot of steps. Building anaconda refers to building the source in place. Packaging refers to creating either a local package or an official build in the Fedora build system. These will be described using the official Fedora build infrastructure.

The first step is having both the anaconda source and the Fedora package source checked out. Checking out the anaconda source is described in detail on the main page. Checking out the package source is described in detail on the
page. For now, let's assume the anaconda source is in src/ and the package source is in pkg/.

The rest of this page is laid out based on what task you are trying to accomplish.

Building the Source

Why might you just want to compile anaconda instead of building a package? Of course, there's the obvious reason that you are working on something in the loader and need to see if your changes still compile. You may also want to build a new loader for testing out in an updated initrd. Also, sometimes it's good to do a test build real quick to make sure sources still compile and translations still work before submitting it to the build system.

First you need all the requirements installed. If you are running the same version of Fedora that you want to build anaconda for (say, you're using F15 and want to build the F15 anaconda sources), this is pretty straightforward. The easiest way to do this is to build a SRPM file and then automatically install all the build requirements from that using the yum-builddep tool included in the yum-utils package.

This may take a little while, but will end up pulling in all the programs required to build anaconda. This includes compilers and basic libraries if you don't already have them installed. Of course, you will need make to build the SRPM. It's possible to build an SRPM without the makefile target, but it's so much less convenient.

Then, building anaconda is a simple matter of:

clumens@exeter:~/src$ make

If you aren't running the same version of Fedora that you want to target a build of anaconda for (say, you're running F15 and want to build the Rawhide anaconda sources), it's still possible. You'll first need to install the mock package and install all the build dependencies of the anaconda package in the right mock chroot. Follow the above instructions through creating an SRPM. Then:

The first time you run this, it will take a long while as it downloads and installs all the package build dependencies. The slower your repos, the longer it will take. Afterwards, you will have a mock chroot populated with all the libraries and programs needed to compile anaconda. You can then chroot into it and do a build:

Building a Test Package and Tree Compose

We no longer automatically generate nightly trees for rawhide. This makes it a little hard to test updates to the loader or tree composition scripts. For this, you need to create a test package of anaconda and then use that test package in a run of pungi to compose a new tree. In order to do those tasks, you need anaconda's build dependencies installed (see above), pungi installed, enough disk space to store a tree, and space somewhere to put a small package repository.

Again, this is easiest if you are building a tree for the same architecture as you will be testing. First, you need to build a new anaconda binary package:

We have makefile targets to do this last bit automatically, but you don't want to use them for test builds. The real targets also add a new %changelog entry to the spec file and tag the build with a GPG signed tag. You don't really want to accidentally push a new tag to the remote repo.

Then you create a new tarball, build an RPM from it, install it to your local system (you need the updated versions of the scripts on the local system for pungi to find), and create a package repo containing the updated package:

At this point, you are all set to run pungi and create a whole new Fedora tree to test with. In order to run pungi, you need the fedora-kickstarts package installed. pungi takes a kickstart file as input and generates a tree using the various repo commands and the %packages section. I copy one of the basic kickstart files from that package as the basis. I remove a bunch of the stuff out of the %packages section since I don't care, and then I add in a new repo line so pungi finds my updated anaconda in preference to whatever we're shipping in the distribution right now (that's also why you've got to update the version number in configure.ac above).

Building an Official Package

Doing an official build of anaconda for Fedora is much simpler because of our Makefile targets and the fact that you don't need to do any tree composition. The first step is to build a tarball from anaconda source. Before doing that, it's good to make sure you've got the latest stuff.

This last command updates the anaconda.spec.in file with a new %changelog entry, increments the version number in configure.ac, and regenerates po/anaconda.pot for the translators. The %changelog entry is made automatically from the git logs, so you should examine what was written to anaconda.spec.in and remove unnecessary messages. We remove 'Sending translation for' messages as well as merge commit messages. When you are finished with anaconda.spec.in, check in the files as 'New version' to signify we are making a new version:

Then you just wait for the package to work its way through the build system. If all goes well, there's nothing left to do. However if the build fails, you can check the provided link and view the log files to determine the cause of the problem. Then it's back to the beginning of the whole packaging process to try again.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.