OSDN Git Service

Merge pull request #196 from mobinmob/boot66_doc
authormobinmob <39646700+mobinmob@users.noreply.github.com>
Thu, 8 Feb 2024 18:08:49 +0000 (20:08 +0200)
committerGitHub <noreply@github.com>
Thu, 8 Feb 2024 18:08:49 +0000 (20:08 +0200)
Boot66 doc

conf/void-66-base-system.md
conf/void-66-distribution-specific.md [new file with mode: 0644]
conf/void-66boot-.md

index 27c0f7f..4ea0614 100644 (file)
@@ -111,4 +111,4 @@ The basic directories and symlinks for runit are also a parta of this package, i
 
 ## Future work :
 
-- Currently 66-void does not include support for apparmor. I believe the best place for that is the upstream `boot-66ser` repository and I plan to sent an MR asap :)
+- Currently 66-void does not include support for apparmor. I believe the best place for that is the upstream `boot-66serv` repository and I plan to sent an MR asap :)
diff --git a/conf/void-66-distribution-specific.md b/conf/void-66-distribution-specific.md
new file mode 100644 (file)
index 0000000..16c38ec
--- /dev/null
@@ -0,0 +1,35 @@
+## 1. Void-specific utilities and changes
+
+During the packaging and integration work for 66 and boot-66serv for voidlinux, differences between the original 66-based distribution (obarun, based on arch linux) were adressed by adjusting the sw and writing some utility scripts. These are documented bellow.
+I **realy** want to stress that point that this is *by no means* a criticism of the upstream choices, but rather a way to adress differences between the systems. Generally speaking 66 and boot@ are distro agnostic.
+### 2. Differences of implementation and policy
+
+There are 4 differences that needed adressing in the voidlinux integration work:
+1. tmpfiles support
+2. systemctl options handling
+3. modules handling and 
+4. efivarfs mounting.
+
+#### 2.1 tmpfiles.d
+
+Obarun reuses archlinux packaging work and that means it needs an implementation of tmpfiles.d and sysusers.d de-facto standards. The later holds no significance for the init work, but tmpfiles.d had an implementation (based on opentmpfiles) and still has a service in boot@ and an assosiated option/key.
+At first, I just set `TMPFILE=no`when runnign ./configure, but that is not a very good solution, because a misconfiguration by users can break the boot. I removed the code and the configuration key altogether prompted by the upstream changes that moved the relevant script to a different repository.
+After some changes it works fine.
+
+#### 2.2 systemctl
+
+The code in `local-sysctl` service is simple and effective, but it does match the relevant runit core-service in voidlinux. My option was to reuse the void-runit code in the service. It works fine, I may tweak it in the future.
+
+#### 2.3. module loading behaviour-handling.
+
+Upstream uses a module loading script written from scratch. It works without glaring issues, but since void-runit includes the `modules-load` utility and my goal was to be as close to the distribution as possible, I reused it.
+`modules-load` is included in the new *66-void* package. The change was also hastened by the move of the upstream script to a seperate git repository.
+
+#### 2.4 efivarfs mode
+
+Void has efivarfs mounted rw by default. That is a matter of policy and I did the change in the `` service.
+
+### 3 Transitioning from runit and reusing existing service scripts
+
+`void-packages` contains 
\ No newline at end of file
index 92abc09..da90ac0 100644 (file)
@@ -4,10 +4,9 @@ In the boot-66serv package there are three small posix shell scripts that try to
 In many cases, running these will be the only step a user needs to get the stage 1 scripts configured correctly.
 These are:
 
-1. 66boot-initial-setup
-2. 66boot-rcdotconf
-3. 66boot-storage-autoconf
-
+1. [`66boot-initial-setup`](https://codeberg.org/mobinmob/66-voidlinux/src/branch/master/srcpkgs/boot-66serv/files/66boot-initial-setup)
+2. [`66boot-rcdotconf`](https://codeberg.org/mobinmob/66-voidlinux/src/branch/master/srcpkgs/boot-66serv/files/66boot-rcdotconf)
+3. [`66boot-storage-autoconf`](https://codeberg.org/mobinmob/66-voidlinux/src/branch/master/srcpkgs/boot-66serv/files/66boot-storage-autoconf)
 ### 2.1 66boot-initial-setup
 
 `66boot-initial-setup` is the first script written. 
@@ -48,9 +47,9 @@ This is accomplised by using `blkid` from `util-linux` to discover the *TYPE* of
 
 These three scripts are in some ways voidlinux-specific:
 
-- `66boot-initial-setup` is implementing policy that is based on the current official voidlinux policy. It does not have much that will help beyond the distribution.
-- [`66boot-rcdotconf`](https://codeberg.org/mobinmob/66-voidlinux/commit/721050e92677a728f2c4f4eccf8b8969eb21447d) is tranlating the voidlinux `/etc/rc.conf`, and while they are other distributions with similar configurations it is not certain that translated to exactly the same or compatible implementation.
-- `66boot-storage-autoconf` is probably the most distribution-independent of the three. But it still has some aspects - such as package names- that are voidlinux-specific. These are clearly documented in the script comments.
+- 66boot-initial-setup is implementing policy that is based on the current official voidlinux policy. It does not have much that will help beyond the distribution.
+- 66boot-rcdotconf is reusing the voidlinux `/etc/rc.conf`, and while they are other distributions with similar configurations files and keys it is not certain that this specific implementation can be reused. When time permits, a test port to a distribution that uses a similar configuration file will be created.
+- 66boot-storage-autoconf is probably the most distribution-independent of the three. But it still has some aspects - such as package names- that are voidlinux-specific. These are clearly documented in the script comments.
 
 Code and ideas from `66boot-rcdotconf` and `66boot-storage-autoconf` has been used to improve the configure script in the upstream boot@ service. If anyone needs to leard the gory details, they can [read the MR comments](https://git.obarun.org/obmods/boot-66serv/-/merge_requests/1).
 
@@ -60,4 +59,4 @@ There is not much to do in adding features to the scripts - they will follow the
 
 There will probably be a feature removal for 66boot-initial setup. Creating trees and populating them will be streamlined and the -effective but crude- way to  do that will be obsolete.
 
-There is a plan to reuse code from `66boot-rcdotconf` and `66boot-storage-autoconf` directly in the configure script of the boot@ service. That will enable seemless and automatic configuration for the user by default, with all the power of the full boot@ environment file available.
+There is a plan to reuse code from `66boot-rcdotconf` and `66boot-storage-autoconf` directly in the configure script of the boot@ service. That will enable *seemless and automatic* configuration for the user by default, with all the power of the full boot@ environment file available if needed.