Anaconda/Building

Building anaconda

Building and packaging anaconda is not hard once you have all the sources checked out. These two tasks will be described separately, even though they are pretty similar. Building is just compiling the handful of programs and libraries. Packaging is building, followed by putting everything together into an RPM. 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/.

Building

Why might you just want to build 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 a new 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 F8 and want to build the F8 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.

clumens@exeter:~$ cd src/
clumens@exeter:~/src$ make src
...
Wrote: /home/clumens/rpm/SRPMS/anaconda-11.4.0.59-1.src.rpm
clumens@exeter:~/src$ yum-builddep /home/clumens/rpm/SRPMS/anaconda-11.4.0.59-1.src.rpm

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 F8 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.

clumens@exeter:~/src$ make src
...
Wrote: /home/clumens/rpm/SRPMS/anaconda-11.4.0.59-1.src.rpm
clumens@exeter:~/src$ mock -r fedora-8-i386 /home/clumens/rpm/SRPMS/anaconda-11.4.0.59-1.src.rpm
...

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:

clumens@exeter:~$ sudo su -
root@exeter:~# mount -o bind /home/clumens/src /var/lib/mock/fedora-8-i386/root/root
root@exeter:~# chroot /var/lib/mock/fedora-8-i386/root/
root:~# make
...

Packaging

Doing an official build of anaconda for Fedora is not hard either. We have some makefile targets to make things much easier. 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.

dcantrel@mitre ~$ cd src/
dcantrel@mitre src (master)$ git fetch && git rebase origin
dcantrel@mitre src (master)$ make bumpver

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:

dcantrel@mitre anaconda (master)$ git add anaconda.spec.in configure.ac po/anaconda.pot
dcantrel@mitre anaconda (master)$ git commit -m "New version."

Now we have the version updated and the spec file template updated. We need to tag the git repository and generate a new release archive. Here's how I do that:

dcantrel@mitre src (master)$ git clean -d -x -f
dcantrel@mitre src (master)$ ./autogen.sh && ./configure
dcantrel@mitre src (master)$ make release

The git tag procedure will attempt to sign the tag using the GnuPG key for the default email address in your local git configuration. If you do not have GnuPG set up, now is a good time.

Now it's time to push the new version changes and tags and move the files over to the package CVS directory. Before you push the changes, it may be necessary to reset the po files to their original state:

dcantrel@mitre src (master)$ ( cd po ; for f in *.po ; do git checkout -- $f ; done )
dcantrel@mitre src (master)$ git checkout -- po/anaconda.pot                            # may not be necessary
dcantrel@mitre src (master)$ git push && git push --tags
dcantrel@mitre src (master)$ mv anaconda.spec *.bz2 ~/pkg/devel/
dcantrel@mitre src (master)$ cd ~/pkg/devel/
dcantrel@mitre pkg$ make upload FILES=*.bz2

Now update the sources file like you are told to and remove the old entry. I also remove old entries from the .cvsignore file. Then continue like so:

dcantrel@mitre pkg$ make clog
dcantrel@mitre pkg$ cvs ci -F clog
dcantrel@mitre pkg$ make tag
dcantrel@mitre pkg$ make clean
dcantrel@mitre pkg$ make build

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.