DeveloperWiki:Automated Package Build System
What is an Automated Build System
One of the best examples of an automated package build systems is the Fedora Koji project, Koji is a continuous build system for all of the rpms in the Fedora and RHEL projects. The main benefit of an automated build system is that all of the packages need to pass through a common gate, a common checkpoint for quality and consistency.
While the Koji build server is referenced heavily the Arch equivalent will need to be very different, in both architecture and the general goals of the project.
The proposed name for the Arch package build system is Quarters, the logic being that what really feeds pacman is quarters.
Alternative naming options will be considered
One of the main aspects of the Arch distribution compared to distributions like Fedora is money. The Fedora project can go out and buy servers by the arm full, but Arch will need to continue to rely on volunteer equipment and working with what we can get our hands on. While these aspects will effect the nature of the package build system, they cannot allow for the compromise of the quality of the Arch Linux distribution.
- Avoid requiring too many daemons
- No Authentication systems
- No database dependencies
- Simple http communication
- Able to interact with distributed components over any reasonable link quality
- Need to be able to distribute the build load to systems all over the world
- All communication needs to be encrypted (duh)
- Builders make decisions by peer review
- Data Model
- Information on the available packages is made by parsing live pacman data (pacman is fast enough)
- Packages to build is presented to the builders via serialized format (probably json)
- All build communication is based on gathering presented data, all pulls, not puts
- All servers are state machines, the status of the distributed build environment is assessed by parsing the "global" state machine
- Command system to move packages manually from the build repos to the final repos
- Build Cleanliness
- Every package is built in its own clean chroot environment
- Packages can be pulled and polled from many sources
- AUR (plugable?)
- Other scms ()
- Web interface
- Building Requirements
- All packages need to be build-able, this includes the base toolchain
- Trigger mass rebuilds of package, with version bumps
- Track Packager data through the build process, don't allow the packager to be lost to the builder
- System Interaction points
- Detached cli interface sends signals to the master
- Master server reads signals and acts on them
It has been proposed that the application be developed in Python. Python is fast enough, has the libs we need, and who doesn't understand python?
Sorry, but this project is too big for bash, and bash is too slow.
I thought about OCaml, but I figured that it should be something that everyone can hack on.
Try and go for python3
Component Build Out
Quarters will consist of a number of individual components. These components are all pieces of the distributed system, the components will also interact via a common language independent medium and https.
Master Server Components
The components required for the operation of the master server
The package parsers will be pluggable modules that return predictable data about the state of source package data stored in either a source control manager or an interface such as the abs or the AUR.
The idea here is that as long as the data queried from the source is uniform there can be any number of usable interfaces. The primary system will need to be svn, since this is what the main package tree is stored in, then git and then an AUR parser. More interfaces can be added on later if we or anyone else wants them.
These components are used by multiple services
Each component will need to be able to present files via an https server. The package will require a standalone https server written in python.
Standard Utils Module
That anoying module that sets up logging and other more globally needed functions