logo

live-bootstrap

Mirror of <https://github.com/fosslinux/live-bootstrap>

DEVEL.md (4138B)


  1. <!--
  2. SPDX-FileCopyrightText: 2021 fosslinux <fosslinux@aussies.space>
  3. SPDX-License-Identifier: CC-BY-SA-4.0
  4. -->
  5. # Development Guidelines
  6. ## Testing
  7. Before making a PR, please test your change locally. It is OK to develop outside
  8. of the live environment, but please be sure to test inside the live environment
  9. and that a full build completes.
  10. ## Structure
  11. ```
  12. seed
  13. ├── seed.kaem
  14. ├── script-generator.c
  15. ├── ...
  16. └── stage0-posix
  17. steps
  18. ├── manifest
  19. ├── any-global-files
  20. ├── jump
  21. │   └── linux.sh
  22. ├── improve
  23. │   └── x.sh
  24. ├── somepackage-version
  25. │   ├── pass1.kaem
  26. │   ├── pass2.sh
  27. │   ├── files
  28. │   ├── simple-patches
  29. │   ├── mk
  30. │   └── patches
  31. ```
  32. The `seed` directory contains everything required for `script-generator` to be
  33. run.
  34. In the `steps` directory, the bootstrap process is defined in `manifest`.
  35. Each package to be built is named `package-version`.
  36. Each subsequent build of a package is the nth pass. Scripts are named
  37. accordingly; eg, the first build would be called `pass1.sh`, the second would be
  38. `pass2.sh`, etc.
  39. Scripts run in kaem era should be denoted as such in their filename;
  40. `pass1.kaem`, for example. Pass numbers do not reset after kaem, ie, you cannot
  41. have both `pass1.kaem` and `pass1.sh`.
  42. In this folder, there are other folders/files. `*.checksums` are
  43. required for early packages that are build with kaem, others are optional.
  44. Permissible folders/files:
  45. - `files`: auxiliary files required for the build distributed by live-bootstrap.
  46. - `mk`: makefiles.
  47. - `patches`: patches for the source.
  48. - `simple-patches`: patches for the source that use the before/after convention of simple-patch.c
  49. - `*.checksums`: files containing the checksums for the resulting binaries and
  50. libraries that are compiled and installed.
  51. - Otherwise, the package's checksum is in SHA256SUMS.pkgs.
  52. - compilation script(s)
  53. ## Conventions
  54. - **Patches:**
  55. - all patches are relative to the directory where the tarball is extracted
  56. - thus, no patch lines for `a/file.c`, but `coreutils-9.4/file.c`
  57. - all patches begin with a patch header
  58. - **parts.rst:**
  59. - all packages are explained in `parts.rst`
  60. - **General:**
  61. - Where possible, all blocks of text should be limited to a length of 80
  62. characters.
  63. - There is no character limit for code, the reasons for this are two-fold:
  64. - Often harms readability.
  65. - Often impossible/hard in early bootstrap stages.
  66. - **Licensing:**
  67. - Generally, the project is licensed under the GNU GPL v3.0 (or any later
  68. version).
  69. - Documentation is licensed under CC-BY-SA-4.0.
  70. - Patches are licensed under the license of the project which they are
  71. patching.
  72. - All files (excluding files within submodules) must comply with REUSE v3.0.
  73. ## `sources` file
  74. The format of the sources file for a HTTP source file is:
  75. ```
  76. <url> <checksum> [filename]
  77. ```
  78. For a Git repository snapshot:
  79. ```
  80. <git url> <URL to HTTP snapshot> <checksum> [filename]
  81. ```
  82. The format of a git url must always be `git://<path to repository>~<reference>`.
  83. `reference` is, for instance, a commit, tag or branch. Always use
  84. Git protocol path, except for GitHub, in which `git://` is automagically
  85. changed to `https://`.
  86. The URL to HTTP snapshot may be `_` (a single underscore) if no HTTP snapshot
  87. exists. In this case, the filename is compulsory. The checksum is of the Git
  88. snapshot, generated with `git archive`. See `mirror.sh` for more detailed rules.
  89. Some specific helpful things:
  90. - prefer `.tar.gz`
  91. - For GitHub, all snapshots are generated with long commit IDs, so use long
  92. commit IDs.
  93. ## Running a mirror
  94. There are 3 things you need to run a mirror;
  95. 1. A tool to perform the mirroring (e.g. `mirror.sh` in this repository); we
  96. encourage diversity in this area.
  97. 2. A server on which to host the mirror; this should have HTTP support, and
  98. optionally HTTPS. It is of greatly diminished utility if it does not support
  99. plain HTTP.
  100. 3. Automatic updates. This should involve updating the Git repository and
  101. updating the mirror as required.