1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
The build system is the heart of the project. On this page you can see the initial plan.
## Files in git repository
For packages that need some customizations, the build system will use a repository that consist from the following files:
- _[package_name]_/_[architecture_name]_.sh: shell script, which will run in the same directory where the original PKGBUILD found. It can do the following things: apply sed lines, apply patches, or even replace the original PKGBUILD file with a custom one.
- blacklist: text file, list of packages that will be ignored by the build system (e.g. cannot build for this architecture).
- build-manually: text file, list of packages that will be added to the build list on update, but need manual interaction before build. Packages that depend on this package will be also hold back.
- update-once: text file, list of packages that will be updated next time even if nothing changed. This list will be cleared out on next update.
## Processes
The build system will consist from the following shell scripts:
- get-package-updates: check for packages that need to be built, and build a list in the proper build order
- build-packages: build packages one by one, then upload the binary package to the repository server
- arch32build: build packages in a clean chroot (a fork of [archbuild](https://git.archlinux.org/devtools.git/tree/archbuild.in))
- db-update: add binary packages to the repository, and remove them from the build list (a fork of [db-update](https://git.archlinux.org/dbscripts.git/tree/db-update))
## get-package-updates
1. Create a lock file for build list.
2. Update git repositories ([official packages](https://git.archlinux.org/svntogit/packages.git/), [community packages](https://git.archlinux.org/svntogit/community.git/) and the repository of package customizations).
3. Read previous git revision numbers from files.
4. Check modified packages from the last update, and put them on a list.
5. Merge the list of newly modified packages with the existing build list, and put them in the proper build order.
6. Write the current git revision numbers to files.
7. Remove the lock file.
## build-packages
1. Read the build list and try to build the packages one by one.
3. Check if the current package or any of its dependencies are locked, broken or blocked. If not, then lock the package.
2. Create a lock file for the current package. If it's already exist, jump to the next package.
4. Copy (or download) the source package and the customizations locally.
5. If it's an architecture-independent package (marked as 'any'), then copy the built package from the official repository, and skip the following three steps.
5. Apply customizations by running the script if exist in a chroot.
6. Run arch32build.
7. If the package fails to build, then try again once. If fails again, then mark it as broken.
8. After a successful build, sign the package with the server's PGP key, and add (or upload) the binary package to the staging directory.
9. Run db-update.
## arch32build
Build the package in a clean chroot environment with a custom makefile.conf.
## db-update
1. Create a lock file for build list.
2. Add binary packages to the repository.
3. Remove the package from the build list.
4. Remove the lock file.
|
