Anaconda/Contribute

Contributing to Anaconda and related projects

This wiki page aims to explain how and where to most effectively contribute to the Anaconda installer and related projects.

Not just Anaconda - choosing where to contribute

The Anaconda installer used to be quite monolitic, but this is no longer the case and there is a growing trend to split parts of Anaconda to separate modules and libraries. This not only help to improve modularity, but also makes it possible to use these libraries outside of the Anaconda installer.

Before contributing to Anaconda or one of its components, it is often necessary to find out which library or component the feature in question is implemented.

What follows is a brief description of the various project under the Anaconda umbrella.

anaconda

The Fedora/RHEL installer itself. All installation-specific code--the GUI, TUI and a lot of glue code--for using the various Anaconda related modules and libraries belongs to the Anaconda project.

pykickstart

A python library for manpulating kickstart files. It contains a data representation of kickstart files, a parser to read the data representation, and a writer to generate kickstart files.

blivet

A python library for examining and manipulating storage configurations.

libblockdev

A library for performing low-level operations with block devices.

lorax

A tool for creating the anaconda install images. It also includes livemedia-creator which is used to create bootable livemedia, including live isos and disk images.

initial setup

An application that can run during the first start of a newly installed computer and makes it possible to configure the computer according to the needs of the user.

python-meh

A python library for handling, saving, and reporting exceptions.

Contributing code

Anaconda and all related projects are open source software and are looking forward to sensible contributions to their source code.

Please view our patch review guidelines for detailed information on the process and policies concerning patch submission. This can be summarized as:

• Patches can be submitted either by email or as a pull request on Github
• All patches are reviewed by other contributors
• If a patch has been accepted, it will be pushed to the repository by a contributor who has commit access

Helping with Anaconda testing

Contributions to anaconda or any projects which fall under the installer umbrella are always welcome. If you are interested in helping out, testing your changes before submitting patches is highly recommended. There are different ways to test changes--the following is only one, relatively simple way.

Pre-requisites

• Anaconda source tree, which can be obtained: https://git.fedorahosted.org/git/anaconda.git
• You can test on bare metal, but this guide assumes testing on a VM using qemu.
• Web space: Having some publicly available web space is helpful for posting updates.img and kickstart files. These are helpful both for your development and for distributing to other people for testing.
• HTTP/FTP server: For testing remote install methods, you'll need a server running that has the correct trees available. These methods are not tested all that often, so this isn't typically all that important. Close to a release, you will want to have access to this however.
• Virtualization: qemu is used here, so grab qemu-kvm, qemu-kvm-tools, qemu-system-x86 and qemu-img

Local branches and creating an updates.img

• By default, you are on master branch. This is "upstream", aka rawhide. Various versions of Fedora follow the form f$releasever-branch.

• Note that while you can test out any changes you wish, you will not be able to push them to any of the remote branches unless you are an approved contributor. If you have patches you'd like to see integrated into the code base, please send a patch or create a pull request in GitHub.

• An easy way to test changes is to create a new, local branch based off of a version of anaconda -- usually the most recently built version, or a last known "good" release. Checkout the release tag, and then create a new branch from this.

git checkout anaconda-22.15-1
git checkout -b newbranch

• Make any necessary changes, and commit them.

git add $files
git commit -m "Some message"

• To test your changes, create an updates.img, which you can load at boot time.

./scripts/makeupdates

• Upload the updates.img to some web space.

Testing out changes

• Grab the latest build of Fedora (the anaconda version your updates.img is built against *MUST* match the the version of anaconda in the Fedora compose you are testing).

• Prepare some empty disk images.

qemu-img create test.img 8G

• Boot the ISO (Note: this allocate 1024MB of RAM. Adjust accordingly based on your resource availability)

qemu-kvm -hda test.img -cdrom ~/isos/boot.iso -boot d -m 1024

• At the splash screen, hit TAB over the "Install Fedora...." entry. This exposes the command line that will be used for booting, where you can add the boot parameter to load your updates.img.

inst.updates=http://path.to/updates.img