Browse code

README.txt

Jaidyn Levesque authored on 2019-10-20 21:33:42
Showing 1 changed files
... ...
@@ -6,7 +6,6 @@ Scripts used to deblob and rebrand OpenBSD source-code, made for the
6 6
 LibertyBSD project.
7 7
 
8 8
 
9
-
10 9
 ----------------------------------------
11 10
 SCRIPTS
12 11
 ----------------------------------------
... ...
@@ -33,8 +32,8 @@ There're five scripts here, so here's what they do:
33 32
 USAGE
34 33
 ----------------------------------------
35 34
 Usage of these scripts is pretty simple-- to make freshly deblobbed OBSD
36
-sources, just run them each with $1 being the directory of the corresponding
37
-source-code, like so:
35
+sources, just run them each with the argument being the directory of the
36
+corresponding source-code, like so:
38 37
 
39 38
 	sh src_deblob.sh /usr/src
40 39
 	sh man_deblob.sh /usr/src
... ...
@@ -53,39 +52,45 @@ NOTES
53 52
 All of the scripts make use of "./libdeblob.sh", and all file-editing/etc
54 53
 operations are abstracted to its functions.
55 54
 
56
-This is because, instead of actually applying changes directly to the source
57
-code of the given directory, the deblob scripts create a set of patches for
58
-the given directory, and, after every patch is created, the patches are
59
-finally applied to the given directory.
55
+This is because instead of actually applying changes directly to OBSD
56
+sources, the deblob scripts create a set of patches for them, and *then*
57
+apply them.
58
+
59
+You might want to perform multiple operations on a given file, (I.E.,
60
+substitute text, then remove a line, etc.). After every operation, a new
61
+(modified) version of the file is created in the /tmp/ directory, along with
62
+a patch. So if you want to do multiple operations, you'll need to decide
63
+whether or not to use the original source-code, or a modified version from
64
+/tmp/...
60 65
 
61
-The making of patches, etc, are abstacted to the functions "ifile" and "ofile".
62
-"ifile" outputs to stdout the file-- be it the patch-file, the original,
63
-whatever is appropriate. "ofile" writes to the patch-file what is piped to it,
64
-and handles the bullocks.
66
+This has been abstracted away with the "ifile" and "ofile" functions.
67
+"ifile" outputs to stdout the contents of the file-- be it the patch-file, the
68
+original, whatever is appropriate. "ofile" writes to the patch-file what is
69
+piped to it, and handles the bullocks.
65 70
 
66 71
 Hence why "ifile | operation | ofile" is so common in libdeblob.sh
67 72
 
68 73
 Each script uses a very clearly-named /tmp/ directory...
69
-	script-name.*/
70
-
71
-... where * is a random string of numbers.
72
-
73
-This *is* more indirect and cumbersome, but it has some nice advantages:
74
-	o Forced Abstraction:
75
-	  When operations *need* to be abstracted, they tend to become more
76
-	  standardized. This leads to easily grokable function-names (rather
77
-	  than potentially obscure command calls)
78
-	o Easy Debugging:
79
-	  Since all patches and their effects are stored in /tmp/ before
80
-	  being applied, one can easily SIGUP and investigate for any
81
-	  problems before the given directory is tainted. Or even if it
82
-	  already has been, it's still easy enough to compare patches, etc.
83
-	o Patch Generation:
84
-	  I mean, yeah, it makes patches. We know that. So for sure, if we
85
-	  want to distribute patches, that's nice. And they'll be distributed,
86
-	  not that it's clear they'll be useful to anyone. Hey, if it's easy
87
-	  to provide for some weird, obscure, barely-hypothetical use-case,
88
-	  why not?
74
+	/tmp/script-name/
75
+
76
+
77
+While it is a *tad* bit weird do all of this indirect work on the sources, it
78
+has a few advantages I'd like to stick with:
79
+	* Abstraction.
80
+		Operations are all very general and unspecific; you don't need
81
+		to manually muck with `sed` for every individual patch.
82
+	* Easy debugging.
83
+		If there's a problem, you can stop the script before it patches
84
+		original sources, and look at the /tmp/ data. Compare the
85
+		.orig with the .patch with the modified, etc. Very useful.
86
+	* Patch generation.
87
+		With patches being integral to the entire process, it makes all
88
+		changes made to OBSD source code very transparent. Anyone could
89
+		take a look at a tarball of the patches and understand *exactly*
90
+		what changed. 
91
+		There're probably some other obscure use-cases for these
92
+		patches, anyway. And if it's easy to support a weird
93
+		hypothetical use-case, why not?
89 94
 
90 95
 ... in order of importance.
91 96
 
... ...
@@ -95,12 +100,12 @@ This *is* more indirect and cumbersome, but it has some nice advantages:
95 100
 BORING STUFF
96 101
 ----------------------------------------
97 102
 Send patches/issues to:
98
-	o <jadedctrl@teknik.io>
99
-	o <#libertybsd> (Freenode)
100
-	o </f/libertybsd> (raddle.me)
103
+</f/libertybsd> (raddle.me)
104
+<#libertybsd> (Freenode)
105
+<jadedctrl@teknik.io>
101 106
 
102 107
 License is ISC (COPYING.txt)
103 108
 Author is Jaidyn Levesque <jadedctrl@teknik.io>
104 109
 Some ports contributions by jmfgdef (Jimmybot),
105
-some improvements by Einhard Leichtfuß.
110
+Some improvements by Einhard Leichtfuß.
106 111
 Source is at https://git.eunichx.us/libertybsd-scripts.git