summaryrefslogtreecommitdiff
path: root/Build-system.md
diff options
context:
space:
mode:
Diffstat (limited to 'Build-system.md')
-rw-r--r--Build-system.md29
1 files changed, 18 insertions, 11 deletions
diff --git a/Build-system.md b/Build-system.md
index aaed199..09a99c3 100644
--- a/Build-system.md
+++ b/Build-system.md
@@ -5,7 +5,14 @@ For packages that need some customizations, the build system will use a reposito
- _[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.
+- 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. This list overrides the 'build-manually' list.
+
+## Build list
+The build list is a text file, and will contain the list of packages that need to be built in the proper build order. One package per line, a line contains the package name, the git revision number and the repository name.
+Along with the build list, there will be a state directory, where the build process could create files for each package, and mark their current status. The files are named as _package name_-git revision_. Possible statuses:
+- locked: this means that a build process is currently running for this package.
+- broken: this means that a build process fails to build the package, requires fixing.
+- blocked: this means that a package is updated, but it's on the 'build-manually' list.
## Processes
The build system will consist from the following shell scripts:
@@ -18,21 +25,21 @@ The build system will consist from the following shell scripts:
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.
+4. Check modified packages from the last update, and put them to the build list. If a package is updated, but already on the rebuild list, then just update the git revision number. If a package is deleted, remove from the rebuild list, and add it to the deletion list. If a new package is added, then ensure that it's not on the deletion list.
+6. Put the list in the proper build order.
+7. Write the current git revision numbers to files.
+8. 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.
+2. Check if the current package or any of its dependencies are locked, broken or blocked (if a state file is available).
+3. Create a state file for the current package and set it as locked.
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.
+7. If the package fails to build, then try again once. If fails again, then mark it as broken (edit the state file if it's still exists).
+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, together with a file which contains the git revision number.
9. Run db-update.
## arch32build
@@ -40,6 +47,6 @@ 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.
+2. Check if the git revision of the binary package is the same as on the build list. If it's different, then drop the package. Otherwise add binary packages to the proper repository.
+3. Remove the package from the build list, and remove the corresponding package state file.
4. Remove the lock file. \ No newline at end of file