rbt 0.13.42 → 0.15.1

data/doc/README.gen

@@ -3,179 +3,65 @@
 
 DEFAULT_HEADER
 
-## RBT - The "Ruby Build Tools" Project
+## Introduction to the "Ruby Build Tools" Project (RBT)
 
 <img src="https://i.imgur.com/PN2lOHj.png"> Welcome to the 
-<span style="color: darkgreen; font-weight: bold">Ruby Build Tools</span> -
-<b>getting work done</b>! <b>Making compiling great again</b>. \o/
+<span style="color: darkgreen; font-weight: bold">Ruby Build Tools</span>,
+also called the <b>RBT suite</b> - <b>getting work done</b>! <b>Making
+compiling great again</b>. \o/
 
-The <span style="color: darkblue; font-weight:bold ">primary goal</span> for
-the **RBT project** is to allow a user to install software, first and
-foremost on **Linux systems**, and typically from **source** - in other
-words: **to simply compile the program** at hand from a **remote URL**.
-
-While the main platform is predominantly the <b>Linux</b> platform, whenever
-possible support for **other platforms** will be added as well; Linux is
-the **main target OS** for the rbt project, though. Most development for
-RBT does indeed take place on a Linux system currently. Ideally we
-could reach a state where we can test the RBT suite on less commonly
-used systems as well, such as **HaikuOS** or **ReactOS** to name
-only a few here. And, of course, the more popular ones such as OSX
-or Microsoft's Windows suite as well, naturally.
-
-<b>So what is the main goal for the <span style="color: darkgreen">
-RBT project?</span></b>
-
-The main goal for the **RBT project** is **to be able to compile a
-program from source**, using a remote URL to some tarball, such as
-the .tar.xz file for <b>evince</b> here →
-https://download.gnome.org/sources/evince/42/evince-42.3.tar.xz.
-
-This should be as simple as doing this:
-
-    rbt evince
-
-That's it! It should never be more complicated than that, for
-well-behaving programs.
-
-While this is the primary goal of the RBT project, the **full
-scope** of the **RBT project** is a significantly wider one:
-the **RBT project** will also attempt to help as **a build
-toolset**, that is, as means to **help people manage
-software** on their respective computer systems in
-general. This may even extend towards other programming
-languages, be it python, java, C/C++, shell scripts - you 
-name it.
-
-Another "higher" meta-goal that follows this vision is to
-integrate tasks that are typicall done by a package manager.
-Support for this within RBT itself is presently (2022)
-still fairly minimal. Do not expect RBT to become a fully
-fledged package manager right now; but, perhaps this use
-case may be covered one day in the future. Until then 
-singular aspects found in different package managers
-may be included into the RBT suite as well.
-
-Yet another goal for the <b>RBT project</b> is to provide
-all the raw data used for managing <b>all</b> programs
-on a <b>Linux Distribution</b> or another Operating
-system. What you do with this data is up to you; I
-simply wanted to have this all available within a
-<b>single</b> project as-is.
-
-The data is primarily stored in various individual cookbook
-.yml files. These .yml files, though, can be turned
-into a SQL dataset. Since as of <b>August 2022</b> it
-is recommended to use a SQL database - but if you are
-fine using .yml files then you can do so. See elsewhere
-in this document more information pertaining to this.
-(Note that the SQL-based approach is not yet sufficiently
-sophisticated; for the time being I will still default to
-.yml files and it may be easier for you to ignore the
-SQL situation for now, and just use the yaml files. In
-the future, though, I expect that we can handle the
-full dataset offered by RBT via SQL.)
-
-As a brief teaser, though, and short explanation to 
-this, consider the program called <b>htop</b> which is stored
-in the file called <b>htop.yml</b>. <b>anjuta</b> is stored
-in <b>anjuta.yml</b> and so on and so forth. If the
-program name contains any '-' character then these
-are ignored, so the program 
-<b>https://download.gnome.org/sources/gnome-commander/1.14/gnome-commander-1.14.3.tar.xz</b>
-would be stored in the .yml file <b>gnomecommander.yml</b>.
-
-This is a rather simple convention - the name of the
-program will become the name of the yaml file in
-question. These so-called individual "cookbooks"
-(aka "to cook/compile a program from source)
-can then be used by other projects. Note that this
-term is a bit similar to the old linux distribution
-called sorcery (https://sourcemage.org/Sorcery).
-
-<b>Is RBT actually useful?</b>
-
-Well - I have used RBT specifically to help me in my attempts to
-**boostrap** a LFS/BLFS (Linux from Scratch / Beyond Linux from
-Scratch) system, so this is an additional use case (and goal) for
-the RBT project as well. So I think that the RBT suite does
-have some use here or there. For this I would coin the phrase
-<b>"from zero to hero"</b> - which means to <b>bootstrap and create
-a Linux system</b> that can be burned on a DVD or simply put on
-a USB device. This is not yet working flawlessly, but it is
-on the TODO list as well: to support LFS/BLFS builds from scratch
-(aka <b>from zero</b>). 
+This <b>documentation</b> attempts to detail the various objectives for
+the RBT project, including its history, as well as how people may benefit
+from the project.
 
-Additionally, the **RBT** project may aid in the process of <b>autogenerating
-files and code</b> related to installing and compiling in general, such
-as **generating standalone shell scripts** or **valid archive formats**,
-such as .rpm or .deb.
+## What is the RBT project about?
 
-For example, one part of **RBT** can be used to <b>autogenerate completion files
-for bash and zsh</b>; I use this to more easily compile programs, such as
-by typing "ry autom<TAB>", to become the very same as "ry automake". This
-thus saves me a few keystrokes on the keyboard.
-
-Another script, part of RBT, can modify **Makefile**s and change the
-prefix in that file, without me having to remember the awkward syntax
-<b>make</b> uses when trying to override the default prefix in
-use. These are examples for such "toolkit" scripts, so the overall
-goal for the RBT suite is to help in regards to such <b>use cases</b>.
-
-In some ways, if you look at the RBT suite from a wider perspective, **RBT**
-attempts to be the **swiss army knife for compilation/installation** of
-software projects. The focus here is on **hands-on use** - it is a
-toolset project and has to offer code/functionality that helps
-solve certain computer-related tasks.
-
-<b>Q: But the RBT suite is so gigantic! I will never need all of
-it.</b>
-
-That's right - you may only need a small subset of the RBT suite. The
-RBT suite attempts to cover different use cases and needs, so it is
-highly likely that not every user needs to use all of the RBT 
-suite.
-
-However had, even if you do not intend to install or compile anything
-through RBT, many different programs are registered in this project,
-which may be of (indirect) help in some other ways, such as if you
-wish to <b>determine which particular binary on a given Linux system
-belongs to which particular application</b>, or if you intend to
-implement a package manager on your own. (The dataset for the
-standalone programs is available under the namespace **RBT::Cookbooks**.
-For a list of all registered programs, you can simply query
-the toplevel-method **RBT.available_programs?**).
-
-Related to this question of "How do users benefit from the RBT
-suite", one part of the RBT suite deals with <b>statistics</b>.
-Support for this is somewhat minimalistic right now. One script reports
-some statistics, such as <b>how many of the registered projects depend on
-cmake, or meson, and so forth</b>. This part will be slowly extended
-over the coming years, but it is not the primary use case for the RBT 
-suite - just something that I found to be interesting to know,
-how many different projects out there depend on which compilation
-strategy. (So many projects still depend on GNU autoconfigure/configure,
-for example, with cmake coming second, and meson/ninja coming third.
-I found that monitoring the rise of meson/ninja to be quite 
-interesting.)
-
-The <b>primary core functionality</b> of the RBT project, however
-had, lies in **compiling programs from source**, as this is what I
-use RBT for on an almost daily basis. It also was the original
-reason why the RBT project was started many ears ago.
+The <span style="color: darkblue; font-weight:bold ">primary goal</span> for
+the <b>RBT project</b> is <b>to support a user whenever the need arises
+to install software, on a given computer system</b>.
+
+The primary operating system in this regard is, first and foremost, 
+<b>Linux operating systems</b> (henceforthwith simply called <b>linux</b>
+in this document.
+
+Additionally, when we refer to allowing a user to install software, 
+this typically refers to taking the <b>source code</b> and compiling
+this source code - in other words: <b>to simply compile the program</b>
+at hand, from a <b>remote URL</b>.
+
+While the <b>primary platform</b> for the <b>RBT project</b> is predominantly
+the <b>Linux</b> platform, whenever possible support for <b>other platforms</b>
+will be added as well. In fact, it is a secondary goal for the RBT project
+to support <b>all</b> platforms ruby is able to run on in the long term. How
+realistic it is to reach that goal is another matter, but as a goal RBT
+will eventually try to support as many different operating systems as
+possible, provided that ruby can run on such a system.
+
+<b>Linux</b> is the <b>main target OS</b> for the rbt project, though,
+so things will be tested on <b>Linux</b> first. Most development for
+RBT does indeed take place on a Linux system currently.
+
+Ideally, in the future, we could reach a state where we can test the
+RBT suite on less commonly used systems as well, such as <b>HaikuOS</b>
+or <b>ReactOS</b> to name only a few here. And, of course, the more
+popular ones such as OSX or Microsoft's Windows suite as well, naturally.
+Windows is the second operating system that RBT will support, by the
+way; it is less well-tested than the Linux-specific code of the
+RBT project.
 
 ## Installing the rbt gem itself
 
-This subsection addresses the possible user question
-<b>How to install the rbt gem?</b>.
+This subsection addresses the possible user question <b>How to install
+the rbt gem?</b>.
 
-The <b>canonical</b> way to install the **rbt** gem is via:
+The <b>canonical</b> way to install the <b>rbt</b> gem, via the
+commandline, goes via:
 
     gem install rbt
 
-However had, I recommend the **--user-install** option; this makes it
-easier to use the **bin/** scripts that are part of this gem, as
-they will reside in your home directory, at **bin/** there:
+However had, I recommend to make use of the <b>--user-install</b> option;
+this makes it easier to use the <b>bin/</b> scripts that are part of this
+gem, as they will reside in your home directory, at <b>bin/</b> there:
 
     gem install rbt --user-install
 
@@ -186,220 +72,542 @@ In older ruby versions the path was simpler; no idea why that changed,
 please ask the rubygems maintainers if you are interested in the
 why.)
 
-While the **/usr/** hierarchy as prefix is fine, in principle, some
+While the <b>/usr/</b> hierarchy as prefix is fine, in principle, some
 distributions, in particular debian, have a habit of splitting up
-gems **a lot**. This makes it harder for users to know where files
-reside - see typical questions asked by users on **IRC**.
+gems <b>a lot</b> (or did so in the past). This makes it harder for users
+to know where files reside - see typical questions asked by users on
+<b>IRC</b>.
 
-This is also another reason why the --user-install option is better,
+This is also another reason why the <b>--user-install option</b> is better,
 in my opinion - you don't have to guess where the executables
 will reside; they are just in the home directory, somewhere there.
 And you can move them from there to any other location anyway,
-or use **symlinks** and/or **aliases** via your shell to setup
+or use <b>symlinks</b> and/or **aliases** via your shell to setup
 the system how <b>you</b> want it to be. Or, use the ruby code
 directly - after all you can create your own executables, since
 that is precisely what all gems do anyway in their corresponding
 **bin/** subdirectory.
 
-Since gems are also **downloaded locally**, and then available as
+Since gems are also <b>downloaded locally</b>, and then available as
 a .gem file, other users can easily install these gems into their
 home directory as well, without depending on a global installation.
 This may be especially useful in environments where you are
 restricted, such as at a **campus/university environment**.
 
-On windows, if you plan to upgrade the rbt gem, I recommend
-to first uninstall all old rbt gems. While this is, strictly
-speaking, not really necessary, I found that it may work
-better if old gems are removed - at the least on windows.
+On windows, if you plan to upgrade the rbt gem, I recommend to first
+<b>uninstall</b> all old rbt gems. While this is, strictly speaking,
+not really necessary, I found that it may work better if old gems
+are removed - at the least on windows. There I manually remove the
+directory where the old ruby stores gems. Again, this is probably
+not strictly necessary, but I found that this works better in the
+long run.
+
+## How does RBT handle compiling from source, explained in a simple manner?
+
+Let us now briefly explain how RBT approaches compiling from a source
+archive: after all that is <b>the main goal for the</b> 
+<span style="color: darkgreen; font-weight: bold">RBT project?</span></b>.
 
-## How I use the RBT project
+Let's take any random remote URL to some tarball archive, 
+such as the <b>.tar.xz file</b> for <b>evince</b> that may
+be found here →
+https://download.gnome.org/sources/evince/42/evince-42.3.tar.xz.
+
+So, to then compile this via the RBT suite, we should be able to
+do something as simple as the following, via the commandline:
 
-This subsection was added in <b>January of 2023</b>. Before
-that time, the content was mostly written down already in
-this document, but it was spread over different sub-topics.
-I decided that it was time to give a more thorough overview
-of the project, from a "<b>my point of view</b>". That way,
-hopefully, other users can learn from how I approach 
-problems that the RBT project tries to solve for you.
+    rbt evince
 
-So, this subsection shall try to helpfully explain **how I
-use the RBT project most of the time**, as that may give
-some indication how the RBT project could be used by
-other people as well.
+That's it! In the above example, <b>rbt</b> refers to the
+executable <b>bin/rbt</b>, which is part of the rbt gem itself.
+
+If all goes well then the above tarball, the file name
+<b>evince-42.3.tar.xz</b>, will be downloaded (unless it
+already exists locally), extracted, and then compiled.
+It all goes well the user will then have the specified
+version of evince installed, compiled from source.
+
+It should never be more complicated than that, for
+<b>well-behaving programs</b>. At the least in theory;
+in practice you can imagine that some things may go
+awry or not work, but this is where <b>rbt</b> will 
+also try to be of help, in order to resolve such
+problems.
+
+Note that while the primary focus is on compiling
+source code as-is, a secondary focus is to allow 
+installation from a binary source, as well as to
+support different package managers, similar to the
+<b>fpm gem</b> (https://github.com/jordansissel/fpm).
+
+This was the brief introduction to how rbt should work
+in theory. Of course there are more details to be
+had, which will be mentioned in other subsections of
+this document.
+
+## The full scope of the RBT project: extended objectives
+
+The content in this document above delineated the primary
+objective for the RBT project.
+
+Of course the <b>full scope</b> of the <b>RBT project</b>
+is a significantly wider one:
+
+The <b>RBT project</b> will attempt to be of help to
+the user as a <b>general-purpose build toolset</b>.
+
+What does this mean? This means that the RBT project
+will try to be of <b>help to people who wish to
+manage the software</b> on their respective computer
+systems in general. This may even extend towards other
+programming languages, be it python, java, C/C++,
+shell scripts - you name it.
+
+Although RBT has started via ruby, other programming languages
+are permissive as well.
+
+Another "<i>higher</i>" meta-goal that follows this vision is
+to integrate tasks that are typicall done via a
+<b>package manager</b>. Support for this within RBT itself
+is presently (2024) still fairly minimal. Do not expect RBT
+to become a fully fledged package manager right now; but,
+perhaps this use case may be covered one day in the future.
+Until then singular aspects found in different package
+managers may be included into the RBT suite as well.
 
-We have to declare a few things upfront, though.
+Yet another goal for the <b>RBT project</b> is to provide
+all the raw data used for managing <b>all</b> programs
+on a <b>Linux Distribution</b> or another Operating
+system. As one example: (almost) all programs that are
+registered in the RBT suite have a remote URL registered -
+see the evince example above.
 
-I use **linux** as my main operating system, so this is also
-the primary operating system for the scripts offered by
-the rbt gem. While I also try to support windows, windows
-at this point in time is a second-class citizen. At a later
-time this may change, but as of 2023 this is still the
-case so.
+What the user then does with this data is up to them; I
+simply wanted to have this all available within a
+<b>single</b> project as-is; and to be able to query
+this via the commandline, too.
 
-On Linux, I often found to have a need to quickly compile
-some software, such as when a new release of a given project
-occurs. For example, say that there is a new **php** source
-archive released.
+The data is primarily stored in various individual cookbook
+.yml files. These .yml files can be turned into a SQL
+dataset. This will at one point in time probably become
+the default way for users to interact with the dataset
+made available by the RBT project. In the past, since
+as of <b>August 2022</b>, it even was recommended to make
+use of a SQL database, but I no longer recommend this
+for now; many things have to be polished in the RBT
+project before we can fully transition into a SQL
+database. For now, prefer to make use of the various
+.yml files that are distributed. See elsewhere
+in this document more information pertaining to this.
 
-So, what do I do in this case?
+This <b>SQL-based approach</b> will eventually be more useful,
+as it should be faster to query its content - in
+particular on <b>Windows</b>.
 
-Well, first, I have to update the local version of <b>php.yml</b>,
-with the new URL to the latest tarball of PHP. This is also
-stored in that **.yml** file, under the <b>url1</b> entry.
+For more objectives of the RBT suite, consider reading
+the subsection called <b>Is the RBT suite actually useful?</b>.
 
-How do I then update the content of said .yml file?
+## What is the policy for program-names stored in .yml files?
 
-I usually start by navigating to the <b>php/</b> subdirectory
-first, of the directory where I keep all source directories
-(which is **/home/x/src/** on my home setup). Strictly
-speaking this cd-operation (change directory) is not necessary;
-the RBT scripts will work fine from other directories too.
-But I found it is easier if I first go to the directory
-where I keep the corresponding source archive. In the
-context of this paragraph, php could then be found
-at <b>/home/x/src/php/</b>. I follow the "one directory
-per program" rule. It is a simple approach.
+Let's consider the program called <b>htop</b>.
 
-Now that I have (hopefully) managed to navigate to the
-source directory at hand (<b>/home/x/src/php/</b>), I
-can then run the following command on the commandline:
+This program will be stored in the file called
+<b>htop.yml</b>.
 
-    incrementversion
-    incr # or just this alias to the above ^^^ instead
+The program called <b>anjuta</b> would be stored
+in the file <b>anjuta.yml</b> and so on and so forth.
 
-This command will actually invoke class
-**RBT::Cookbooks::IncrementProgramVersion** which will
-try to find a new upstream release tarball, using **curl**
-or **wget*+ to check if such a remote tarball exists. 
-Note that I use many aliases on my home system; all
-aliases are kept in the gem called <b>rcfiles</b>.
+If the program name contains any '-' character, as part
+of their name, then these '-' characters (the hyphen)
+are ignored. So, for instance, if the remote URL
+to a program is like this:
 
-Now, if the remote file specified at url1 in the
-file called php.yml exists then it will be 
-<b>downloaded</b> the moment I try to compile
-the program at hand (in this case php).
+https://download.gnome.org/sources/gnome-commander/1.14/gnome-commander-1.14.3.tar.xz
 
-So I can simply type this:
+then the corresponding .yml file would be called
+<b>gnomecommander.yml</b>. In other words: the 
+'-' character is ignored, as far as the name
+for the .yml file is concerned.
 
-    rbt php
+This is a rather simple convention - the name of the program will become
+the name of the yaml file in question.
 
-And if things go alright from that point forward (which they
-tend to do, at the least for php and many other programs
-that can be compiled), then php will have been compiled
-and installed afterwards into the /usr/ prefix, or the
-AppDir prefix on my home system, which would be
-**/home/Programs/Php/8.0.3/**, for instance. That's
-it for the most part: I just compiled a program from
-source.
+These .yml files are so-called individual "cookbooks". This name derives
+from "<b>to cook/compile a program from source</b>.
 
-So, as you can see, this is actually quite simple to use,
-in principle. I don't want to make this really more complicated
-than that. In fact: I even simplify the above, by using
-the alias "<b>trad</b>", which will first update, by incrementing
-the version (of php), download the actual source archive, 
-extract the source archive and then compile php into the
-/usr/ prefix, which is the "traditional" prefix (hence the
-abbrevation "trad").
-
-From a historic point of view, it was somewhat too tedious for
-me to keep on compiling things manually, via the old
-"./configure; make; make install" route, so it made sense
-to me to create some scripts in ruby that could simplify
-this for me. Back in 2004 when I was using Linux, I
-discovered **GoboLinux**,  which is a great distribution, with
-an excellent philosophy. I did not understand the shell scripts
-they used, though, so I tried to write (and re-create) the
-logic behind it in <b>ruby</b>.
-
-This goal of making RBT compatible with GoboLinux still exists
-as of today: the RBT project must work on GoboLinux, out of
-the box. I have not tested this in quite some time, though ...
-need to do so eventually.
-
-But the RBT project has other goals as well, aside from this:
-more common goals. As a project, RBT tries to **remain flexible**,
-so that people can repurpose this project to their own use
-cases.
+Take note that this term is a bit similar to the old linux
+distribution called sorcery (see https://sourcemage.org/Sorcery).
+
+## Is the RBT suite actually useful?
+
+This is an interesting question.
+
+I have used RBT specifically to help me in my attempts to
+<b>boostrap</b> a LFS/BLFS (Linux from Scratch / Beyond Linux from
+Scratch) system, so this is an additional use case (and goal) for
+the RBT suite as well.
+
+I think that the RBT suite does have some real value here - or
+there. For this I would like to coin the phrase <b>"from zero
+to hero"</b> - which means to <b>bootstrap and create a Linux
+system</b> that can be burned on a DVD or simply put on
+a USB device. This is not yet working flawlessly, but it is
+on the TODO list as well: to support LFS/BLFS builds from
+scratch (aka <b>from zero</b>). 
+
+Additionally, as yet-another-objective, the <b>RBT</b> project may
+aid in the process of <b>autogenerating files and code</b> related
+to installing and compiling in general, such as
+<b>generating standalone shell scripts</b> or **valid archive formats**:
+archive formats such as <b>.rpm</b> or <b>.deb</b>.
+
+For example, one part of <b>RBT</b> can be used to <b>autogenerate completion files
+for bash and zsh</b>; I use this to more easily compile programs, such as
+by typing "ry autom<TAB>", to become the very same as "ry automake". This
+thus saves me a few keystrokes on the keyboard.
+
+Another script, also part of the RBT suite, can modify <b>Makefiles</b> and
+change the prefix in that file, without me having to remember the awkward
+syntax <b>make</b> uses when trying to override the default prefix in
+use. These are examples for such "toolkit" scripts in RBT, so the overall
+goal for the RBT suite is to help in regards to such <b>use cases</b>. The
+primary use case remains on <b>compiling source code</b> as-is, though.
+
+We could continue this listing here, but I think the basic point was
+already pointed out now. If you look at the <b>RBT suite</b> from a wider
+perspective, <b>RBT</b> attempts to be a <b>swiss army knife for
+compilation/installation</b> of software projects. The focus here
+lies on <b>hands-on use</b> - it is a toolset project and has to
+offer code/functionality that helps solve certain computer-related
+tasks.
+
+## The rewrite of the RBT project in February 2024
+
+In <b>February 2024</b> it was decided to rewrite the RBT project, yet again.
+
+This subsection will briefly explain why.
 
-I really want to be able to use the project on linux, on windows,
-on <b>mac OS X</b>, on the various BSDs, ideally also on haiku and
-so forth one day. <b>One project to rule them all!</b> \o/
+There were various smaller reasons - a few bugs, a few things that
+have to be improved, and so forth. Some of these bugs were very
+old, and I haven't gotten around to fixing them, so this provided
+an opportunity here.
 
-This means that **RBT** has to remain flexible, as much as that
-is possible. It has to be adaptable to different operating
-systems on the fly; or at the least easily.
+But, the biggest reason for the rewrite was something else: I wanted
+to transition into <b>well-defined actions</b> for the RBT project.
+Other subsections of this document will explain the rationale
+behind <b>well-defined actions</b> more; suffice to say that I
+wanted to have all important, actionable activities tied together
+and have them be usable via the commandline as well. This would
+allow me to tap into the RBT project without having to rely solely on
+classes and methods - instead I can use actions to do individual steps,
+such as symlinking files, copying files, performing post-installation
+steps and so forth. If I want to apply some patches automatically then
+I could do so too, such as:
 
-Additionally, **I want to use different prefixes**. Most
-existing package managers make it hard to install applications
-into a particular prefix, and have things work from there.
+    rbt sed --apply-the-patch
 
-For example, debian does not allow you to use a layout
-similar to how GoboLinux works by default. I don't know
-why they do not allow it - probably because nobody wrote
-the code for dpkg/apt to handle different prefixes.
+Or, via actions, from the commandline:
 
-From that original goal that was historically the **bootstrap phase**
+    rbt_action apply_the_patch sed
+
+Yes, there is not much difference between these two variants, but the above
+entry-point, via rbt_action, allows us to think in terms of actions first,
+<b>rather</b> than the program name first. Plus, I could provide specific
+individual actions in a specific order, which I can not easily do via
+commandline --flags.
+
+## A theoretical remark from potential users of the RBT suite: „But the RBT suite is so gigantic! I will never need all of it.“
+
+That's right - you may only need a small subset of the RBT suite, and
+that's ok. The RBT suite attempts to cover different use cases and
+needs, so it is highly likely that not every user needs to use <b>all</b>
+of the RBT suite.
+
+However had, even if a user does not intend to install or compile anything
+through RBT, many different programs are registered in this project,
+which may be of (indirect) help in some other ways. For instance, if a
+user desires to <b>determine which particular binary on a given Linux system
+belongs to which particular application</b>, or if the user intends to
+implement a package manager on his or her own, then the RBT suite may
+be useful, as it allows such potential users to query this through the
+RBT suite.
+
+The dataset for the standalone programs is available under the namespace
+<b>RBT::Cookbooks</b>. For a list of all registered programs, you can
+simply query the toplevel-method called <b>RBT.available_programs?</b>.
+
+Related to this question of "<i>How do users benefit from the RBT suite?</i>",
+one part of the RBT suite deals with <b>statistics</b>. Support for this is
+somewhat minimalistic right now, but will be extended in the future. One script
+reports some statistics, such as <b>how many of the registered projects depend
+on cmake, or meson, or GNU configure, or a Makefil and so forth</b>. You can
+query their percentage value, and thus gain a little insight into how
+different projects make use of which particular build tool. That is an example
+for statistical information. 
+
+This part about statistics will be slowly extended over the coming years, but
+it is not the primary use case for the RBT suite - just something that I found
+to be interesting to know, how many different projects out there depend on
+which compilation strategy, and how this may change over the years. Presently,
+in the year 2024, many projects still depend on GNU autoconfigure/configure.
+cmake comes second, meson/ninja comes third. I found that monitoring the rise
+of meson/ninja to be quite interesting, and I expect that this trend will
+continue. Of course the subset that is registered in RBT is not the 
+<b>full</b> picture, so the statistics are only valid <b>in regards to
+the RBT suite itself</b>. Globally we may see a completely different picture,
+but the statistics shown by RBT are correct when it comes to the programs
+registered in the RBT suite.
+
+The <b>primary core functionality</b> of the RBT project, however
+had, will remain on <b>compiling programs from source</b>, as this is
+what I use RBT for on an almost daily basis. It also was the original
+reason why the RBT project was started many years ago.
+
+## How do I use the RBT project personally?
+
+How do I use the <b>rbt project</b> primarily, on my <b>Linux</b> systems,
+but also on windows?
+
+This paragraph, added in <b>January of 2023</b> and extended in
+<b>February of 2024</b>, will try to give a useful answer to this
+question in a unified manner - hence its own subsection here.
+
+Other users of the RBT suite may understand the goals of the RBT
+suite better after such an explanation was given to them - a
+more thorough overview of the RBT project, from a "<b>my point
+of view</b>". That way, hopefully, other users can learn from
+how I approach problems that the RBT project tries to solve for
+you.
+
+This subsection attempts to helpfully explain <b>how I use the RBT
+project most of the time</b>, as that may give some indication how
+the RBT project could be used by other people as well. We must
+define and declare a few things next.
+
+I use <b>linux</b> as my main operating system, so Linux is the
+primary operating system for the code offered by the rbt gem, as
+was already pointed out elsewhere in this document. While I try
+to support windows as well, windows at this point in time is a
+second-class citizen. At a later moment in time this may change,
+but as of 2023 and 2024, this is still the case so. Some things
+may not work well on windows, whereas they may work well on
+Linux.
+
+On Linux, I often found to have a need to quickly compile some software,
+such as when a new release of a given project occurs. For example, say
+that there is a new <b>php</b> source archive released.
+
+So, what do I do in this case when I want to compile php from
+source?
+
+Well, first, I have to update the local version of <b>php.yml</b>,
+with the new URL to the latest tarball of PHP. This is also
+stored in that <b>.yml</b> file (aka <b>php.yml</b>, under the
+<b>url1</b> entry there.
+
+How is the content of said .yml file then updated?
+
+I usually start by navigating to the <b>php/</b> subdirectory first, of
+the directory where I keep all source directories, which is <b>/home/x/src/</b>
+on my home setup.
+
+Strictly speaking this cd-operation (<b>change directory</b>) is not necessary;
+the RBT scripts will work fine from other directories too. But I found it is
+easier if I first go to the directory where I keep the corresponding source
+archive. In the context of this paragraph, php could then be found in the
+subdirectory at <b>/home/x/src/php/</b>. I follow the "one directory
+per program" rule - it is a very simple approach.
+
+Now that I have (hopefully) managed to navigate to the source directory at hand
+(<b>/home/x/src/php/</b>), I can then run the following command on the commandline:
+
+    incrementversion
+    incr # ← or just this alias to the above ^^^ instead
+
+This command will actually invoke class
+<b>RBT::Cookbooks::IncrementProgramVersion</b> which will
+try to find a new upstream release tarball, using <b>curl</b>
+or <b>wget</b> to check if such a remote tarball exists.
+ 
+Note that I use many aliases on my home system; all aliases are kept in
+another gem, called <b>rcfiles</b>.
+
+Now, if the remote file specified at <b>url1</b> in the file called
+<b>php.yml</b> exists then it will be <b>downloaded</b> the moment I
+try to compile the program at hand (in this case php).
+
+So, via the commandline, I can simply type this:
+
+    rbt php
+
+<b>If</b> things go alright from that point forward - which they tend to
+do, at the least for php and many other programs that can be compiled - 
+then php will have been compiled and installed afterwards into the
+<b>/usr/</b> prefix, or the <b>AppDir prefix</b> on my home system,
+which would be <b>/home/Programs/Php/8.3.3/</b> in this case,
+for instance. That's it for the most part: <b>I just compiled a
+program from source</b>, and all I had to do was to type
+<b>rbt php</b>. \o/
+
+(Actually, for historic reasons, I use "ry" rather than "rbt", so
+the real command is even shorter.)
+
+At any rate, as can be seen, using <b>rbt php</b> is quite simple.
+I purposely did not want to make this more complicated than that.
+
+In fact: on my home system I further simplify the above, by using
+the alias "<b>trad</b>", which will first update the program
+at hand (in this case php), by incrementing the version number
+(of php), then try to download the actual source archive, extract
+the source archive and then compile php into the <b>/usr/</b>
+prefix, which is the "traditional" prefix (hence the abbrevation
+"trad" I am using here). Of course you can do something different,
+such as using <b>usr</b> as an alias rather than <b>trad</b>;
+my brain is just so used to <b>trad</b> as invocation example
+that I keep on using that.
+
+A little historic detour comes next ...
+
+From a historic point of view, it was somewhat too tedious for me
+to keep on compiling things manually, via the old <b>"./configure; make;
+make install"</b> route, so it made sense to me to create some scripts
+in ruby that could simplify this for me. Back in 2004 when I was
+using Linux, I discovered <b>GoboLinux</b>, which was a great
+distribution, with an excellent philosophy. I did not understand the
+shell scripts they used, though, so I tried to write (and re-create)
+the logic behind it in <b>ruby</b>.
+
+This goal of making RBT compatible with GoboLinux still exists as of
+today: the RBT project must work on GoboLinux, out of the box. I have
+not tested this in quite some time, though ... need to do so
+eventually. Unfortunately GoboLinux is also no longer really developed
+actively anymore, so this goal is no longer as important. Nonetheless,
+should GoboLinux ever make a comeback, I'll retain this objective,
+and try to write code in a flexible manner to help support this
+goal.
+
+Having different goals, as part of the RBT suite, reinforces the
+statement that RBT tries to <b>remain flexible</b>. This flexibility
+should then allow different use cases, subsequently allowing 
+users of the RBT suite to repurpose this project to their own
+needs.
+
+As already stated elsewhere in this project, I really want to be
+able to use the project on linux, on <b>windows</b>, on
+<b>mac OS X</b>, on the various BSDs, ideally also on HaikuOS
+and so forth one day. <b>One project to rule them all!</b> \o/
+
+This means that <b>RBT</b> has to remain sufficiently flexible, as
+much as that is possible. It has to be adaptable to different
+operating systems on the fly; or at the least easily.
+
+Additionally, <b>I want to be able to use different prefixes</b>.
+Most existing package managers make it hard to install applications
+into a particular prefix, and have things work from there. They
+tend to assume that the only prefix that is valid is the
+<b>/usr/</b> directory.
+
+For instance: <b>debian</b> does not allow you to use a layout similar
+to how GoboLinux works, by default. I don't know why they do not allow
+for it - probably because nobody wrote the code in dpkg/apt to handle
+different prefixes. I dislike that we do not enjoy this flexibility
+here.
+
+From that original goal that was historically the <b>bootstrap phase</b>
 of the RBT project, I added more and more code over time. I did want
 to provide better error messages as well, and hints how to resolve
-something whenever a problem happens - way before **StackOverflow**
-existed.
-
-Most compile-related errors are quite useless and cryptic to
-newcomers. They don't understand the problem domain. So RBT also
-tries to help users in that regard. Errors may be collected, and
-then something useful is displayed on the commandline - at the least
-that is one goal for the RBT project. This may not always be very
-useful, but at the least that is one goal for the RBT
-project. The code for this is not ideal; I am slowly
-rewriting it since March 2020. (Actually, I think I may have
-to rewrite the whole project past 2021 one day; but I delay this
-for now. I want to be better prepared before I rewrite it.)
-
-I can compile most of the programs that are listed in RBT
-via the following commands:
+something whenever a problem happens - way before <b>StackOverflow</b>
+existed. The goal here was to try to automatically solve problems,
+if the RBT suite has enough information available to do so.
+
+Most <b>compile-related errors</b> are actually quite useless and cryptic
+to newcomers, but also to more experienced users; sometimes they are
+even bogus and misleading and flat out incorrect. Newcomers often do not
+understand the problem domain, so RBT also tries to help users in that
+regard. Errors may be collected, and then something useful is displayed
+on the commandline - at the least that is one goal for the RBT project.
+This may not always be very useful or work in a reliable manner, but at
+the least that is one goal for the RBT suite. The code for this is not
+ideal; I am slowly rewriting it since as of <b>March 2020</b>. (Actually,
+I think I may have to rewrite the whole project past 2021 one day; but
+I delay this for now. I want to be better prepared before I rewrite
+it. In <b>February 2024</b> I finally hit the bullet and started the rewrite.)
+
+The programs that are part of the RBT project I can usually compile by
+just issuing any of the following commands:
 
     rbt NAME
     rbt php
     rbt python
 
-and so forth, so this is really convenient. I don't depend on
+and so forth, so this is really convenient for me. I don't depend on
 another package manager that upstream developers control.
 
-In **September 2021** I decided to cut back on time investment
-for the RBT project. This is mostly because other projects
-take away more of my time. I won't abandon rbt, but it should
-be pointed out that I am mostly only doing maintenance work,
-fixing some problems here and there, polishing this or that -
-but it is a very beta-ish project, and I can not make any
-guarantee that the project will ever leave its beta-ish 
-roots.
-
-## How do I use the RBT project personally
-
-How do I use the **rbt project** primarily, on my **Linux** systems?
-
 What follows next is, more or less, a description of generic use
 cases that I may face on a daily basis.
 
-When I compile a (new) program via **RBT**, such as by issuing "compile
-htop" or "rbt htop" or "ry htop" (I make use of aliases a lot), then
-the **RBT-scripts** will (try to) compile the program **htop** for me,
-as specified by the corresponding "htop.yml" file, which is part of
+When I compile a (new) program via <b>RBT</b>, such as by issuing "<b>compile
+htop</b>" or "<b>rbt htop</b>" or "<b>ry htop</b>" (I make use of aliases a lot),
+then the <b>RBT-scripts</b> will (try to) compile the program **htop** for
+me, as specified by the corresponding "htop.yml" file, which is part of
 the RBT project - within the **Cookbooks** namespace. Hence, within
-**RBT::Cookbooks**.
+<b>RBT::Cookbooks</b>.
 
 If I need to make a change to the compilation process, such as by
-using a different default **prefix**, then I simply edit the
-**htop.yml** file, change, add or remove the corresponding entry,
+using a different default <b>prefix</b>, then I simply edit the
+<b>htop.yml</b> file, change, add or remove the corresponding entry,
 and things will (should) work past this point - but I can also
 override the settings from the commandline, so I have all the
 flexibility required available.
 
-This, in turn, means that I control most of what I compile via
-.yml files, first and foremost - a text file. Other package managers
-do something similar if you look at them. Arch, for instance,
-uses PKG_BUILD or some file like that; gentoo uses ebuilds,
-debian also uses some designated files, and so forth.
+## Defined actions in the RBT suite - well-defined, actionable components
+
+A <b>defined action</b>, in regards to the RBT project, refers to an
+action that will <b>always</b> "<i>stay the same</i>". Such actions
+yield <b>reproducible results</b>. They also should not require of the
+user of the RBT project to know the class-name or the file-name (of
+the .rb file that handles this task) as such whatsoever - this is a
+detail that is not necessary to know. It is thus some kind of 
+abstraction.
+
+Some of these action allow for some flexibility.
+
+For instance, the <b>extract-action</b> handles input with a leading :
+character as if a full path was desired by the user.
+
+So, take this commandline invocation:
+
+    action_extract :htop
+    actionextract :htop
+
+This will be just about identical to, for instance, the following
+variant:
+
+    actionextract /home/x/src/htop/htop-3.2.3.tar.xz
+
+If you compare these two invocation examples of the <b>extract-action</b>
+then you can see that in the first variant you can omit many characters,
+as it is much shorter - and thus more convenient on the commandline.
+
+Of course certain classes, such as class <b>RBT::Action::Installer</b>,
+will extract the source archive for you anyway, but I wanted to have
+individual actions, such as the extract-action, also available
+as a singular, actionable entry point from the commandline.
+
+Note that this only works if you have already downloaded
+the source archive, and moved it to its corresponding
+location (which class RBT::Action::Installer) will also do,
+by default.
+
+This can be done manually, for instance, via:
+
+    rbt --download=htop
+
+I control most of what I compile via .yml files, first and foremost - a
+simple text file. Other package managers do something similar if you look
+at them. Arch, for instance, makes use of <b>PKG_BUILD</b> or some file
+like that; gentoo uses <b>ebuilds</b>, debian also uses some designated
+files, slackware uses its own minimalistic package manager, and so forth.
 
 The "default settings" that I may use for these programs go into 
 a specific .yml file, whereas the **commandline switches** allow
@@ -409,9 +617,9 @@ the AppDir prefix makes a lot of sense. On **slackware** on the
 other hand I may decide to just use **/usr** as option given
 to **--prefix=**.
 
-On **traditional** linux distributions, **/usr** as prefix is
+On <b>traditional</b> linux distributions, **/usr** as prefix is
 not the only possibility of course. Another popular way is to
-compile into the **user's home directory**. A commandline switch
+compile into the <b>user's home directory</b>. A commandline switch
 exists for the latter, for the RBT project, called **--home-directory**.
 This is equivalent to whatever the user's home directory ought to
 be, such as **/home/debug/** or **/home/joe/**. (I typically have
@@ -419,7 +627,7 @@ a user account called **debug** on my systems, which is mostly
 concerned with debugging something on the target computer.)
 
 So, --home-directory for the user joe would be equivalent to
-**--prefix=/home/joe/**.
+<b>--prefix=/home/joe/</b>.
 
 This is useful in the sense that, ideally, I can get away with only
 passing the name of the program that is to be compiled, without
@@ -427,75 +635,72 @@ needing to change anything. It allows me to be lazy - and
 just get things to "work", when they are compiled (if the compilation
 process itself will work).
 
-## Most recent release series (some kind of "changelog" entry)
-
-The most recent release series is <b>version 0.12.x</b>.
+## Code conventions for the RBT suite
 
-It is a smaller release compared to the 0.11.x series.
+The RBT suite contains quite a lot of ruby code. Over time, in particular
+when I have not worked on rbt for weeks or even months, I tend to forget
+some of the simpler conventions. Thus, this subsection helps me remember
+some of these conventions. It may also serve as an additional
+documentation for the project.
 
-The reasons for releasing version 0.11.x were:
+Without further ado:
 
-- I needed to add support to compile from source, via
-a sqlite-database. Hence class RBT::CompileViaSQLDatabase
-has been added. This was actually the primary reason for
-the rewrite: I had to re-arrange the internal logic
-anyway, so I thought that I should start from a
-sqlite-database this time. This is also easier to use
-on windows - one database to rule them all. The trade-off
-is that you have to install sqlite on windows but this
-is quite trivial; see the download link for sqlite
-on windows (the .exe file).
+    absolute_path: This can be used as a replacement for File.absolute_path().
+                   Not only is it a bit shorter, but it will also ensure
+                   that there is a trailing '/' character. 
 
-The location of the database should be a path such as
-<b>/home/Temp/rbt/database/registered_programs.db</b>
-or <b>/tmp/rbt/database/registered_programs.db</b>
+## Time investment into the RBT suite
 
-- I wanted better GUI support, in particular via libui, so that
-this all works fine on windows as well. I also wanted to add
-more screenshots.
+Time is a finite resource of us humans. Naturally there is a limit
+how much code we can maintain - and how much time we can invest
+into a given project.
 
-- I needed better support on windows too, so the rewrite
-had this as one goal.
-
-- Clean-up in general, including removal of old, unmaintained
-software.
-
-- Extend all actions. That is, note down everything in the
-RBT suite that can be done via such actions.
+In <b>September 2021</b> I decided to cut back on time investment
+for the RBT project. This is mostly because other projects
+take away more of my time, including non-computer centric activites.
+I won't abandon rbt, but it should be pointed out that most of the
+time I am now doing maintenance work, fixing some problems here and
+there, polishing this or that - but the RBT suite is still rather
+of beta-ish quality, and I can not make any guarantee that the
+project will ever leave its beta-ish roots.
+
+In <b>February 2024</b> I invested more time into the project by
+rewriting it again - and polishing it while doing so. While I can
+not guarantee to invest as much time into the project, every
+once in a while I will probably fix lots of small and also
+larger things in the project.
 
-For version 0.12.x the primary change was to simply
-remove class RBT::Compile. Use class RBT::Installer instead.
+## Most recent release series (some kind of "changelog" entry)
 
-In the future there may be some larger changes coming to
-the rbt project, including a possible rewrite - perhaps I
-may transition into a full action-based variant of RBT,
-where the actual class at hand does not matter as much
-anymore. Stay tuned for updates in this regard.
+I no longer keep detailed changelog entries, as they are too much
+effort to maintain. Instead I will use the time to improve the
+documentation of existing code.
 
 ## The future outlook for the RBT project past June 2023
 
-Some time ago I realiased that the RBT project is not
-"ideally setup". What does this mean?
+Some time ago I realised that the RBT project is not "ideally setup".
+What does this mean?
 
-Well - there are various big classes, such as class RBT::Installer.
+Well - there are various big classes, such as class <b>RBT::Action::Installer</b>.
 It works fairly ok-ish, but in May 2023 I noticed that it suddenly
-reported errors when there were only warnings. This then led to
-failure of installation.
+reported errors when there were only warnings shown before. This then
+led to failure of installation.
 
-I know how to fix that bug (may take me two hours or so, which I
-simply don't always have), but ... that's just one bug. There
-are several additional bugs like that, and I often seem to 
-invest time merely to deal with architectural deficits.
+I know how to fix that bug (may take me two hours or so, which I simply
+don't always have), but ... that's just one bug. There are several
+additional bugs like that, and I often seem to invest time merely to
+deal with architectural deficits. Time is a finite resource, so I can
+not always invest the time to fix messy code.
 
-Meanwhile I started to use actions - such as stored in RBT.action() -
-and I believe this is the future of the RBT project. I simply want
+Meanwhile I started to use <b>actions</b> - such as stored in RBT.action() -
+and I believe this to be the future of the RBT project. I simply want
 to capture ALL actionable events through a unified handler - in
-this case RBT.action().
+this case, as mentioned, via RBT.action().
 
 For instance, sometimes on a new computer system, I want to 
 compile sed statically into an appdir prefix such as 
 /home/Programs/Sed/4.11. But it may fail and then give a bogus
-error. I want to be able to do step-wise actions, and check
+error. I want to be able to do step-wise actions here, and check
 each one in its own right - a bit like the GNU gdb debugger,
 so that I can see where the problem is, and work around it.
 In classical GNU configure-based projects I may have to sift
@@ -505,7 +710,7 @@ automatically.
 
 So I decided that I will eventually transition into a fully
 actionable-setup of the rbt gem. I will still maintain 
-RBT::Installer and improve it, but at the same time I will
+RBT::Action::Installer and improve it, but at the same time I will
 transition towards actionable snippets. I will use them
 kind of like individual components/objects, until the
 whole rbt suite becomes more reliable. I want it to 
@@ -514,10 +719,10 @@ having to care much about the oddities of each individual
 component.
 
 In the long run we will move some of the functionality
-found within <b>RBT::Installer</b> into actions, and subsequently
-replace the logic stored in class RBT::Installer with
+found within <b>RBT::Action::Installer</b> into actions, and subsequently
+replace the logic stored in class RBT::Action::Installer with
 those actionable callbacks. So, one distant future, 
-class RBT::Installer may just be the general wrapper over
+class RBT::Action::Installer may just be the general wrapper over
 all actions. This will take quite some time, a few years
 perhaps, so do not expect anything to work in the nearby
 future, for now.
@@ -550,7 +755,7 @@ primarily to let the user know which class is handling a
 specific step of the installation/compiling process.
 
 The class name will typically be shown via :: such as
-<b>RBT::Installer</b>.
+<b>RBT::Action::Installer</b>.
 
 If an external class is called then the arrow symbol
 → will be used.
@@ -904,7 +1109,7 @@ project, primarily to make syncing the code easier. The **RBT::Cookbooks**
 namespace handles the source files' logic, whereas RBT itself handles
 how to interprete this information, in particular through the main
 class to use for compiling something, which is the class
-**RBT::Installer**. (The old class RBT::Compile has been deprecated
+**RBT::Action::Installer**. (The old class RBT::Compile has been deprecated
 in <b>2022</b>.)
 
 When you have a look at the RBT project, including the documentation
@@ -927,7 +1132,7 @@ route.
 • The **second reason**, and more important one, is that I want to treat
 users as intelligent people, so I will try to explain to them how 
 some of the RBT internals work. Naturally not all of RBT will be
-explained that way, but more important parts, such as e. g. **RBT::Installer**
+explained that way, but more important parts, such as e. g. **RBT::Action::Installer**
 in particular, will have several entries that will explain what is
 done, and why. My ideal aim would be to actually write a specification
 as a text, and then let ruby simply parse and evaluate that text -
@@ -1115,10 +1320,10 @@ doing a backup, hence why just one letter was used there.)
 
 As other users of the **RBT** project may wish to use another
 directory rather than the one listed above, such as
-a directory like **/Files/Archives/** or **/Depot/Archive/**
+a directory like <b>/Files/Archives/</b> or **/Depot/Archive/**
 or anything like that, there are essentially **three different
 ways** how to define your own target directory for keeping
-such **source archives**:
+such <b>source archives</b>:
 
 (**1**) Simply set a new target altogether, via the **toplevel-method**
 called **RBT.set_source_base_directory()**. A shorter API exists
@@ -1529,7 +1734,7 @@ over time. The slackware support is a bit better since I myself mostly use
 slackware and GoboLinux, but the slackware support in cookbooks/rbt still
 requires quite some more polish and clean-up before it can be easily used.
 
-The **RBT project** is in some ways similar to the LFS/BLFS project
+The <b>RBT project</b> is in some ways similar to the LFS/BLFS project
 in that it attempts to put together information that would be useful for
 when a user wishes to compile some program from source, in particular
 when these programs are requiring modifications to their build system,
@@ -1577,7 +1782,7 @@ this command:
     cookbooks --archive-directory?
 
 There, source files can be stored, such as **htop-2.0.2.tar.xz**
-or **ruby-2.4.1.tar.gz** and so forth.
+or <b>ruby-2.4.1.tar.gz</b> and so forth.
 
 Since many other users may wish to use another base directory for
 their archives, you can define another archive directory on the
@@ -1596,7 +1801,7 @@ Or use the more prevalent rbt name:
     rbt --set-source-dir==/Files/Archive/
 
 The above would assume that all source archives will be stored
-within the **/Mount/USB1/last_backup/src/** hierarchy.
+within the <b>/Mount/USB1/last_backup/src/</b> hierarchy.
 
 Since as of April 2019, the following shorter variant can also be used
 instead:
@@ -1919,7 +2124,7 @@ the following command:
     gem install rbt
 
 Do note that some functionality can work outside of the RBT::Cookbooks
-namespace, such as **RBT::Libtool** related actions.
+namespace, such as <b>RBT::Libtool</b> related actions.
 
 Now, when the above installation method has worked - and if it has not,
 please do consider reporting this - you should be able to compile
@@ -2068,7 +2273,7 @@ This requires the configuration option time_compilation set to
 true it the corresponding yaml file (within the <b>configuration/</b>
 subdirectory).
 
-If this setting is set to <b>true</b>, then RBT::Installer will show, on the
+If this setting is set to <b>true</b>, then RBT::Action::Installer will show, on the
 commandline, how long it took to compile a program, in seconds (and also
 in minutes). The default for this setting is <b>true</b> as of <b>January
 2018</b>.
@@ -2076,7 +2281,7 @@ in minutes). The default for this setting is <b>true</b> as of <b>January
 Note that the time it took to compile the given program at hand will
 only be shown if there was no proble/error during the compilation
 process. This may be fine-tuned at a later time, but for now, the
-functionality at the least exists as part of <b>RBT::Installer</b>.
+functionality at the least exists as part of <b>RBT::Action::Installer</b>.
 
 The time it took, in seconds, will also be stored in the file
 called <b>database_storing_compile_times.yml</b>, in a simple key-value
@@ -2100,8 +2305,8 @@ flag such as this:
     rbt package_cookbooks
     rbt --package_cookbooks
 
-This will create a directory in /Depot/Archives/ and package the
-RBT Scripts into that directory.
+This will create a directory in <b>/Depot/Archives/</b> and package
+the RBT Scripts into that directory.
 
 Of course you can do so manually as well, but I wanted to have
 this functionality at the least available for when a user is
@@ -2169,8 +2374,7 @@ in the respective cookbook file (in this case dosbox.yml).
 The <b>svn_url</b> setting must be specified, as otherwise RBT
 can not download the code via svn.
 
-It is quite rare that source archives depend on svn
-nowadays, though.
+It is quite rare that source archives depend on svn nowadays, though.
 
 ## Creating a .yml yaml file for a specific program
 
@@ -2221,8 +2425,7 @@ in ENV, in ruby files.
 
 Since as of <b>April 2018</b>, there is a way to specify
 another target for the <b>SRC_DIRECTORY</b>, that is - the
-directory under which all other local source-archives
-reside.
+directory under which all other local source-archives reside.
 
 On my home system, the source directory resides under
 <b>/home/x/src/</b>.
@@ -2237,7 +2440,7 @@ is available.
 
 Do note that the variable <b>RBT_SOURCE_DIRECTORY</b> will
 <b>overrule every other setting</b>, except for values
-set from the commandline to RBT::Installer, such as via
+set from the commandline to RBT::Action::Installer, such as via
 <b>--use-this-source-directory=</b> - so use this variable
 with care. If you do not need it, I recommend to simply not
 set it at all; it really only exists in the event that
@@ -2362,7 +2565,7 @@ examples:
 
 The code for this resides in the method
 **try_to_output_how_many_processors_this_computer_has**, which
-is part of **class RBT::Installer**. (This statement is correct at
+is part of **class RBT::Action::Installer**. (This statement is correct at
 the least for **October 2018**).
 
 ## Compile/Installation shell
@@ -2475,7 +2678,7 @@ section of this README file.
 To query all available programs, do:
 
     rbt --all_available_programs?
-    installer --all_available_programs? # or use RBT::Installer.
+    installer --all_available_programs? # or use RBT::Action::Installer.
 
 ## Checking for binary duplicates
 
@@ -2599,7 +2802,7 @@ Keep in mind that you can also use the LFS/BLFS instructions. They
 are available via the "blfs" entry in the respective .yml cookbook
 file.
 
-**Glibc** is obviously also a target candidate that could/should
+<b>Glibc</b> is obviously also a target candidate that could/should
 be upgraded eventually, but this is a rather delicate step - many
 programs have to be recompiled if your glibc version changed.
 
@@ -2810,15 +3013,15 @@ You can show the last updated programs, currently, by default, being
 
 If you want to show the default configure options for a program
 on the commandline, then consider making use of class
-**RBT::Cookbooks::ShowConfigurationOptions**.
+<b>RBT::Cookbooks::ShowConfigurationOptions</b>.
 
-I have it aliased to **sco**.
+I have it aliased to <b>sco</b>, for convenience.
 
-Then I can do the following, in a GCC extracted directory:
+Then I can do the following, in a GCC extracted directory for instance:
 
     sco gcc --ntrad
 
-This will show the following String:
+This will show the following String on the commandline:
 
     ./configure --prefix=/home/Programs/Gcc/10.3.0 --enable-languages=c,c++,d,fortran,objc,obj-c++ --disable-bootstrap --disable-libstdcxx-pch --disable-multilib 
 
@@ -2827,6 +3030,12 @@ I can then use this string to compile GCC 10.3.0 from scratch.
 I needed this so that I can more easily ad-hoc compile
 programs from source as well.
 
+Since as of February 2024 a standalone .sh file will also be
+created. That way you can invoke it without having to type
+anything manually. I needed this in the event that I could
+not start the xorg-server but had to <b>compile LLVM</b> 
+specifically.
+
 ## Auto-removing .la files
 
 If you do not like **.la files** (libtool files), you can set the configure
@@ -3272,11 +3481,12 @@ as such but can be changed by the user; it just happens to be /Programs/
 on my system, but you could take any other name too, such as /pkg/ or
 /home/programs/ and so forth.)
 
-**class RBT::CleanupSystemTags** can eliminate stray (non-existing)
-symlinks, and it is invoked from class RBT::Installer, so the directory
-at **/System/Tags/** will be guaranteed to **not** have any stray symlinks
-whenever RBT::Installer is run. (This is checked in the **post-installation**
-part of class RBT::Installer.)
+<b>class RBT::CleanupSystemTags</b> can eliminate stray (non-existing)
+symlinks, and it is invoked from <b>class RBT::Action::Installer</b>, so the
+directory at **/System/Tags/** will be guaranteed to <b>not</b> have
+any stray symlinks whenever RBT::Action::Installer is run. (This
+is checked in the <b>post-installation</b> part of class
+RBT::Action::Installer.)
 
 The class **RegisteredTags** can be used to register all available
 tags in a .yml "database".
@@ -3312,11 +3522,11 @@ handled by the RBT project.
 
 In general, the main functionality resides in the file
 **rbt/toplevel_methods/symlink.rb**. When it comes to class
-**RBT::Installer then the file is rbt/compile/symlink.rb**.
+**RBT::Action::Installer then the file is rbt/compile/symlink.rb**.
 
 Certain settings in the cookbook .yml files can be used to do
 some trivial symlinking jobs, such as symlinking **lib64/** to
-**lib/**. The boolean setting **autosymlink_lib64** handles this.
+<b>lib/</b>. The boolean setting **autosymlink_lib64** handles this.
 If you need such a symlink-job during post-installation, then
 set this entry to true in the respective .yml file, such as for
 the program called **poppler** and the associated **poppler.yml**
@@ -3361,7 +3571,7 @@ into the /usr/lib/ directory. The name for this class is fairly unwieldy,
 but I needed the functionality in a specific .rb file that I could
 call from the commandline.
 
-By default, RBT::Installer does **not** make use of this class, but you
+By default, RBT::Action::Installer does **not** make use of this class, but you
 can enable it via any of the following commandline flags:
 
     rbt gtk+ --symlink-into-usr-lib-dir
@@ -3401,7 +3611,7 @@ ones:
     libsigc++-2.99.11.tar.xz
 
 Now you may wish to compile all these, into their proper prefix,
-such as that **libsigc++-2.10.1** will end up in **/Programs/Libsigc++/2.10.1/**
+such as that <b>libsigc++-2.10.1</b> will end up in **/Programs/Libsigc++/2.10.1/**
 and so forth. In fact, this is precisely why I added this functionality.
 I needed to be able to compile different versions, including old versions,
 into the corresponding hierarchy under **/Programs/**.
@@ -3563,7 +3773,7 @@ not absolutely rely on this method, but for most programs this
 should work fine.
 
 The code for this resides in the file
-**rbt/toplevel_methods/infer_build_system.rb**.
+<b>rbt/toplevel_methods/infer_build_system.rb</b>.
 
 Some projects may use more than one build system, e. g. harfbuzz
 would allow you to use either **configure** or **meson**. In
@@ -3573,14 +3783,18 @@ method could just "pick" one variant and return it. The latter
 is presently (January 2019) the current default. A yaml file
 keeps track of which build system is prioritized by default.
 
+(Note that in February 2024 this is currently broken; I'll
+rewrite it eventually and probably split up the functionality
+into two separate methods.)
+
 ## The RBT project supports colours on the commandline.
 
-By default, the scripts available within **module RBT** support
+By default, the scripts available within <b>module RBT</b> support
 colours on the commandline. Colours may help put proper focus
 on what is important and what is not.
 
-If, for any reason, you do not want to use colours, you can disable
-them either via the **configuration** (in the .yml file), or use
+If, for any reason, you do <b>not</b> want to use colours, you can
+disable them either via the **configuration** (in the .yml file), or use
 this toplevel API to disable colours:
 
     RBT.disable_colours
@@ -3589,7 +3803,7 @@ this toplevel API to disable colours:
 The above method-call will completely disable colours for the whole
 RBT namespace.
 
-The **configuration file** that is used to determine whether to use
+The <b>configuration file</b> that is used to determine whether to use
 colours is called <b>use_colours.yml</b>. Since not everyone may
 be able to modify the .yml file, depending on the host setup (such
 as in a restricted environment like at a university campus site), a
@@ -3929,7 +4143,7 @@ The leading ' - ' in the line above is for **YAML** and it denotes an entry that
 is to be kept as an Array. The rest of this Array is quite easy to understand.
 The instruction <b>copy_files</b> will simply copy several files; and these files
 are denoted within the **square brackets { }**. These entries can b a file or a
-directory and **RBT::Installer** will correctly handle these.
+directory and **RBT::Action::Installer** will correctly handle these.
 
 The very **LAST entry** is the target location that you wish to copy these
 files to, which in the above case is at
@@ -3977,7 +4191,7 @@ target, one can use this:
 
 This requires that the program is to be compiled via an
 appdir prefix (such as via --ntrad or --apdir on the
-commandline, to <b>RBT::Installer</b>).
+commandline, to <b>RBT::Action::Installer</b>).
 
 Since as of June 2022 you can also invoke the postinstall
 action from the commandline.
@@ -4036,7 +4250,7 @@ In the respective cookbook file, as far as the RBT gem is concerned,
 support for autogen will be handled via the corresponding entry
 called <b>use_autogen</b>.
 
-If this entry is set to **true** (or **yes**), then **RBT::Installer**
+If this entry is set to **true** (or **yes**), then **RBT::Action::Installer**
 will <b>invoke autogen</b> for that particular program, before
 trying to run <b>./configure</b>.
 
@@ -4048,7 +4262,7 @@ out on the commandline:
 
 The result may be output like this:
 
-    RBT::Installer: No, autogen will NOT be used for the program pacman.
+    RBT::Action::Installer: No, autogen will NOT be used for the program pacman.
 
 To specifically enable autogen for the current invocation
 run you can use:
@@ -4223,7 +4437,7 @@ By default, most **.yml** files that are part of the RBT project will
 make use of the **GNU configure** build system - e. g. **configure**,
 **make** and **make install**. You can, on the commandline, determine
 which build system is to be used; and you can also instruct
-**RBT::Installer** to **use another build system**.
+**RBT::Action::Installer** to **use another build system**.
 
 For example, if you wish to specifically use **configure**, then
 you can do this:
@@ -4588,7 +4802,7 @@ you can see the following line:
 
     configure_command_to_use: ./configure.sh
 
-It thus specifies that RBT::Installer will make use of that
+It thus specifies that RBT::Action::Installer will make use of that
 **configure.sh** shell scripts rather than the more generic
 **configure** invocation run.
 
@@ -4895,7 +5109,7 @@ The class was added in November 2019 to the rbt project.
 Some problems and errors may happen during compilation or
 installation of programs.
 
-These are handled internally by RBT::Installer, but they will
+These are handled internally by RBT::Action::Installer, but they will
 also be registered in a module-method onto the RBT Namespace.
 
 It is available via the following code:
@@ -4913,12 +5127,12 @@ be done by the following commandline flag:
     rbt --dont-stop-on-errors
     rbt --ignore-errors
 
-This would instruct **RBT::Installer** to **not** stop on
+This would instruct **RBT::Action::Installer** to **not** stop on
 errors and instead (try to) continue.
 
 ## Pre-install actions
 
-**Pre-install actions** are actions taken before **RBT::Installer**
+<b>Pre-install actions</b> are actions taken before **RBT::Action::Installer**
 will invoke the configure script, or cmake invokation.
 
 Typically the pre-install action(s) may involve calling a shell
@@ -4988,7 +5202,7 @@ if you forgot the name and don't want to look up or can
 not look up, you can try to leverage class 
 **RBT::MapThisInputToThatRegisteredProgram**.
 
-class **RBT::Installer** also makes use of that class if the
+class **RBT::Action::Installer** also makes use of that class if the
 input is not a registered program.
 
 ## Configure profiles / decorators
@@ -5125,7 +5339,7 @@ do so, via <b>rbt</b> like in the following examples:
     rbt --create-program=python-3.3.3
 
 Do take note that CreateAppDirSkeleton may be called from some RBT scripts,
-in particular **RBT::Installer**. Some directories will not see that
+in particular **RBT::Action::Installer**. Some directories will not see that
 their default symlink (called **Current**) is removed, such as gcc or
 binutils, as otherwise subsequent compilation runs would not work
 to the **Current** not being set properly.
@@ -5215,7 +5429,7 @@ like so:
 
     create_pkgconfig :htop
 
-This means that RBT::Installer will be used internally, and then
+This means that RBT::Action::Installer will be used internally, and then
 generate the file **htop.pc**. (In this case create_pkgconfig
 is an alias to **bin/create_pkgconfig_file**).
 
@@ -5562,133 +5776,36 @@ and this is resolved in general. This way the RBT project
 will also attempt to teach and educate people about 
 compile-related problems.
 
-## BLFS - Beyond Linux From Scratch (and also LFS)
-
-**class RBT::Blfs** has "support" for BLFS in that it will ... simply
-show a URL to the remote BLFS page of a given package, if it exists,
-on the commandline.
-
-If you only need to know the URL to the **BLFS homepage**, to embed
-it for display into a webpage perhaps or to display it onto the
-commandline, you can use the following simple **toplevel-API**
-for this:
-
-    RBT.blfs(:name_of_the_program_goes_in_here)
-    RBT.blfs(:openssl) # => "https://www.linuxfromscratch.org/blfs/view/8.1/postlfs/openssl.html"
-
-    # You can also use a String as input to the method rather than a Symbol:
-    RBT.blfs('ruby') # => "https://www.linuxfromscratch.org/blfs/view/svn/general/ruby.html"
-
-This will return the remote BLFS page, as URL (a **String**, actually),
-if it exists, and if it has been registered in the corresponding 
-.yml file (cookbook file for the program at hand; in this example
-the file **openssl.yml**). If no BLFS entry has been registered
-then **nil** will be returned by this method.
-
-You can also use class **RBT::LFS** to build/create a LFS from scratch.
-This is presently (**2019**) quite incomplete, though, and will not work.
-Lots of different things have to be done in the correct sequence before
-a LFS can be built from scratch successfully, and possible errors have to
-be checked before the build can continue. In the long run, for the future,
-this will eventually work, one day - but for now it is an incomplete stub
-and not recommended for testing much at all. It is simpler to use the 
-slow, semi-manual approach for now.
-
-If you wish to quickly **paste** the BLFS page of a given program onto
-the commandline, for display purpose, then you can do something
-like this:
-
-    rbt php --parseblfs
-
-Since as of **September 2021** a bin/ script exists for this functionality.
-This was already planned back in **August 2019**, but I finally had a 
-good use case (support for my older laptop) to add it. The executable
-is called **paste_blfs** and you can use it in this way:
-
-    paste_blfs ruby
-    paste_blfs htop
-
-Since as of **December 2019**, it is now also possible to display,
-on the commandline, **any** registered BLFS entry. This will help
-in the event that you can not access the xorg-server at the moment,
-yet still require information for different packages (I faced
-exactly this problem, so I then added that functionality to RBT).
-
-In order for this to work, you evidently need to have a working
-**internet connection** available - but in principle, the information
-stored in the BLFS project could be zipped up and distributed
-too, within the RBT project.
-
-For the time being, though, only pasting is supported - there is
-no plan to bundle the information into the RBT project at this
-stage in time.
-
-Usage example for this functionality:
-
-    rbt --parse-blfs-page-for=llvm
-
-In **December 2019** another feature was added - the ability to
-make use of the BLFS instructions directly, and run them.
-
-The idea here is that you may wish to compile some program
-from source, but may not access a working xorg-server, as
-you are working on the commandline only.
-
-Invocation example:
-
-    rbt kerberos --use-blfs-instructions # Compile kerberos in the BLFS way.
-
-Since LFS/BLFS is such a useful project, the RBT suite has some
-more support in this regard. This is unsurprising, as the
-<b>Linux From Scratch</b> (LFS) Project has instructions
-on how to compile programs from source. So it has a somehwat
-similar meta-goal, like RBT.
-
-These instructions are immensely useful. A lot of the information
-from LFS/BLFS was integrated into the RBT project.
-
-Many individual cookbook yaml files can point towards the
-LFS/BLFS page, which will often contain additional useful
-information in case you get stuck with something.
-
-You can try to show this URL by doing this:
-
-    blfs curl
-
-This would show the BLFS remote URL of the program called
-<b>curl</b>.
-
-Since as of <b>July 2017</b>, you can also directly paste the
-content of the remote BLFS webpage onto the terminal, if there
-is a remote BLFS page associated with a given program.
-
-The way to do this is as follows:
-
-    rbt gcc --paste-blfs-page
-
-If you want to show all programs that have a blfs entry, use the
-following command:
-
-    rbt --show-programs-with-a-blfs-entry
-
 ## Copying archives to the current working directory
 
-I sometimes needed to be able to copy source archives to the current
+I sometimes need to be able to copy source archives to the current
 working directory. One reason as to when this was necessary was
 when I was about to compile a linux-from-scratch system. There I
-needed to have all archives available.
+needed to have all archives available. Another use case I have
+had was to compile musl in a chrooted environment, and I wanted
+to only (automatically) copy source archives that I needed, rather
+than all of them.
 
-Anyway, say that you wish to copy binutils, gcc and ruby.
+Anyway, say that you wish to copy <b>binutils</b>, <b>gcc</b> and
+ruby, so three different source archives.
 
-You can do so via:
+You can do so via the following class:
 
     require 'rbt/utility_scripts/copy_these_archives.rb'
     RBT::CopyTheseArchives.new(%w( binutils gcc ruby ))
+    RBT.copy_these_archives(%w( binutils gcc ruby )) # Or use this method instead; it does the same as ^^^ above.
 
 Or invoke it from the commandline, via bin/copy_these_archives:
 
     copy_these_archives binutils gcc ruby
 
+Since as of March 2024 this is also available via RBT.actions().
+
+The entry-point would be either :copy_these_archives or just
+:copy. The latter may change (or not); the former, aka :copy_these_archives,
+will remain as-is. But I don't expect :copy to change either, so
+you are probably well-off using the shorter :copy.
+
 ## Simple AppDir confugre
 
 The following API:
@@ -5940,7 +6057,7 @@ project. I am open to extend this functionality to allow other
 projects to use another dataset, though.
 
 The boolean constant **ALSO_AUTOMATICALLY_INSTALL_THE_UPDATED_GEM**,
-defined in class RBT::Installer, controls whether the updated gems
+defined in class RBT::Action::Installer, controls whether the updated gems
 will automatically be installed by the RBT project. If set to
 true then RBT will not only download the respective gem, but
 also install it. Since not everyone may want this, the constant
@@ -6055,7 +6172,7 @@ fully describe an individual recipe (cookbook). Just
 look the .yml file and you should have all the data
 necessary to compile the program at hand - of course
 you may still need wrapper code that actually makes
-use of that dataset, such as **RBT::Installer** does
+use of that dataset, such as **RBT::Action::Installer** does
 normally.
 
 ## KDE
@@ -6405,7 +6522,7 @@ you to automatically attempt to download a missing file.
 
 ## The method try_to_find_an_alias_to_this_input_unless_the_program_exists()
 
-The method **try_to_find_an_alias_to_this_input_unless_the_program_exists()**
+The method <b>try_to_find_an_alias_to_this_input_unless_the_program_exists()</b>
 can be used to find an alias name to a given input.
 
 For example, the input **xorgser** will be converted to **xorgserver**. This
@@ -6983,10 +7100,10 @@ which problem may have been encountered while compiling
 a program.
 
 Users of RBT should be able to fully disable coloured output
-at any moment in time. See the section **controlling the
-output of class RBT::Installer**.
+at any moment in time. See the section <b>controlling the
+output of class RBT::Action::Installer</b>.
 
-## Controlling the output of class RBT::Installer
+## Controlling the output of class RBT::Action::Installer
 
 By default, IO.popen() is used to parse the result of
 system-calls, and colourize some of them.
@@ -7109,13 +7226,15 @@ dataset has to exist locally.)
 
 ## class RBT::Cookbooks::ExpandedCookbook
 
-**class RBT::Cookbooks::ExpandedCookbook** has been created in **August 2020**.
-The main idea is that, in the long run, we will use different "backends" for
-the cookbook dataset (the individual cookbook recipes), including SQL datasets.
+<b>class RBT::Cookbooks::ExpandedCookbook</b> has been created in <b>August 2020</b>.
+
+The main idea behind this class is that, in the long run, we will use different
+"backends" for the cookbook dataset (the individual cookbook recipes),
+including SQL datasets.
 
 That way we the user can decide which variant to use, with different advantages.
-For example, class RBT::Cookbooks::ExpandedCookbook is quite a bit **faster**
-than class RBT::Cookbooks::Cookbook, but not as versatile.
+For example, class RBT::Cookbooks::ExpandedCookbook is quite a bit <b>faster</b>
+than class <b>RBT::Cookbooks::Cookbook</b>, but not as versatile.
 
 ## Cmake
 
@@ -7128,7 +7247,7 @@ Anyway - **cmake support** is available within the RBT project too,
 to some extent.
 
 If you want to compile specifically via cmake, making use of
-**class RBT::Installer**, then you can use the following instruction
+**class RBT::Action::Installer**, then you can use the following instruction
 on the commandline:
 
     --use-cmake
@@ -7696,10 +7815,10 @@ is the rationale as to why that functionality has been added.
 
 **LLVM** offers the **clang compiler**. Compiling most programs should
 be possible via **clang**. The content of the configuration file
-**use_this_compiler.yml** tells RBT::Installer which compiler to
+**use_this_compiler.yml** tells RBT::Action::Installer which compiler to
 favour. If clang is available, and the content of the file
 use_this_compiler.yml is clang, then clang will be used - 
-otherwise RBT::Installer will default to **gcc**, as the latter is
+otherwise RBT::Action::Installer will default to **gcc**, as the latter is
 more commonly used than clang (in 2020 at the least).
 
 The environment variable **RBT_USE_THIS_COMPILER** can overrule 
@@ -7874,121 +7993,45 @@ be given to meson:
 
     --wrap-mode=nodownload
 
-## Licence of this project
 
-Now to some semi-boring legalese, aka the "no warrant disclaimer"
-in particular.
+## highest.rb - showing the highest n programs
 
-Forst, copyright notice:
+You can use the file highest.rb to show the largest local
+programs, a Top 50 for instance, by doing:
 
-Copyright 2022 Robert A. Heiler
+    rbt --highest
 
-Up until the beginning of **April 2021**, the rbt project was
-using the <b>GPL-2.0 licence</b> (no later clause).
+You can specify an argument to it to denote how many
+programs to find. It defaults to 20 programs right now
+if no such argument is supplied.
 
-In **April 2021**, though, I decided to switch to the **MIT**
-licence instead for this project. The older GPL code will
-remain available for some time, most likely at the least a
-full year, perhaps even longer. But the older code is now 
-deprecated as far as I am concerned; others would have to
-maintain it. I only focus on the MIT variant from this
-point onward.
+    rbt --highest=50
 
-You can read up on the MIT licence here:
+## find_alternative_archive.rb
 
-https://opensource.org/licenses/MIT
+^^^ Use this when you could not find an existing
+    archive first. After this has failed, we can try
+    to check if we have to download a new archive.
 
-To make it even more explicit, let me additionally formulate
-the no-warranty disclaimer:
+## new_cookbook.rb
 
-The source code is <b>provided as is</b>. No explicit
-guarantees are given of any kind whatsoever.
+^^^ Use this when you wish to create a new yaml
+    file.
 
-Whenever possible, bugs will be fixed. However had, do
-not expect there to be no bugs in this software suite.
-Chances should be fairly high that it will run on
-your system.
+## scan_source_archive.rb
 
-Why was it decided to switch to MIT rather than GPL?
+^^^ Use this when you wish to scan through the
+    local Source archive. This class will report which
+    entries are missing.
 
-Well, there are several reasons.
+## merge_cookbooks.rb
 
-First, and most importantly: while I will continue to maintain
-the project here for a long while (I am using it on a daily
-basis after all), it is not really a project I particular "care"
-about in the sense of wanting to restrict how users use it. It
-is just a ruby gem, not anything I am using for a "mission-critical
-project". It also is not important to me in regards to my 
-financial status; nothing against donation by interested 
-folks, but I did not create the project for any of that.
-I created the project mostly because I needed to compile
-software or otherwise install software.
+^^^ Use this when you wish to create one big
+    new cookbookfile containing all other entries.
 
-Second, though, the GPL is a strict licence. This can be very
-useful - see the Linux Kernel. You may also depend less on 
-corporations controlling the whole software stack, so the GPL
-has quite laudable goals. But ... is the GPL really important
-for a project like this one here? I am not sure. I think you
-can already "generate value" if a project is useful, so the 
-licence then is of a secondary concern, in particular when
-it is a smaller project anyway.
+## generate_machomebrew_formula.rb
 
-These were my two main reasons. There are a few smaller issues,
-such as the MIT licence being <b>much</b> simpler to use and
-adhere to, but by and large these were the main reasons.
-
-And if a company ever decides to want to make use of RBT
-then I feel flattered, anyway - it means that the project
-has some real value after all, right? Otherwise people
-would not use it.
-
-Be wary of bugs, though; even the MIT licence comes with a
-"no warranty" clause, so always test things first in a
-secure environment (chrooted jail environment, for instance,
-then you can copy or package the compiled packages to 
-wherever you need them(.
-
-While I use this project since over a decade, my use cases
-may not be the same as how other people use the project.
-
-## highest.rb - showing the highest n programs
-
-You can use the file highest.rb to show the largest local
-programs, a Top 50 for instance, by doing:
-
-    rbt --highest
-
-You can specify an argument to it to denote how many
-programs to find. It defaults to 20 programs right now
-if no such argument is supplied.
-
-    rbt --highest=50
-
-## find_alternative_archive.rb
-
-^^^ Use this when you could not find an existing
-    archive first. After this has failed, we can try
-    to check if we have to download a new archive.
-
-## new_cookbook.rb
-
-^^^ Use this when you wish to create a new yaml
-    file.
-
-## scan_source_archive.rb
-
-^^^ Use this when you wish to scan through the
-    local Source archive. This class will report which
-    entries are missing.
-
-## merge_cookbooks.rb
-
-^^^ Use this when you wish to create one big
-    new cookbookfile containing all other entries.
-
-## generate_machomebrew_formula.rb
-
-^^^ Use this to generate a machomebrew formula.
+^^^ Use this to generate a machomebrew formula.
 
 ## GNOME
 
@@ -8123,7 +8166,7 @@ functionality. It is available via:
 
 There is a configuration setting available as part of the **RBT
 project**, called <b>use_ccache</b>. If this is set to yes, aka 
-**enabled*, then the RBT project, in particular **RBT::Installer**,
+**enabled*, then the RBT project, in particular **RBT::Action::Installer**,
 will attempt to **make use of ccache for compilation**.
 
 This **may speed up repeated compilation cycles** of the same
@@ -8288,7 +8331,7 @@ An example for this in regards to meson can be found in the
 file **networkmanager.yml**.
 
 Some of these configure options can be directly passed to an
-instance of class **RBT::Installer** as well.
+instance of class **RBT::Action::Installer** as well.
 
 For example, if you wish to use **--enable-shared** then you can
 simply pass it, like so:
@@ -8487,11 +8530,11 @@ into the /usr/ prefix as well as an AppDir prefix.
 Note that this does not yet work 100% perfectly, because
 RBT uses a different variant to compile such programs,
 based on "logic snapshots" - these are individual steps
-that are taken. Right now class RBT::Installer can not
+that are taken. Right now class RBT::Action::Installer can not
 handle them perfectly well. In the future this may all
 be re-organized and work better at one point in time,
 but for now this has to suffice. The whole compile-logic
-behind RBT::Installer became too complex. I will split
+behind RBT::Action::Installer became too complex. I will split
 this up eventually into smaller, logical chunks - perhaps
 even store them into a yaml file.
 
@@ -8667,7 +8710,7 @@ the documentation, and may add some features here and there.
 But the grand goals may never be achieved, simply due to lack
 of time and dedicated effort.
 
-In **December 2021** I thought about adding "actions" and
+In <b>December 2021</b> I thought about adding "actions" and
 "actionable events" to the RBT project. Please look at the
 subsection **Defined actions in the RBT project** for more
 information about this.
@@ -8944,7 +8987,7 @@ to the rbt suite.
 Some problems and errors may happen during compilation or
 installation of programs.
 
-These are currently handled internally by <b>RBT::Installer</b>,
+These are currently handled internally by <b>RBT::Action::Installer</b>,
 but they will also be registered in a toplevel-method
 onto the RBT Namespace.
 
@@ -9323,7 +9366,7 @@ by step. First step is to no longer allow it to handle
 <b>bin/</b> and <b>sbin/</b> entries. At a later time it
 may be removed completely.
 
-class RBT::Installer was taken as base to create RBT::Install
+class RBT::Action::Installer was taken as base to create RBT::Install
 in <b>September 2022</b>. Several old code parts were
 removed. For instance, @internal_hash[:original_input] was
 removed, as well as the two method names input? 
@@ -9395,46 +9438,8 @@ Consider the following two uses cases:
 Only one of these two would compile. The other one would
 show this error:
 
-    RBT::Installer: The licences do not match. Expected licence
-    RBT::Installer: was: GPLv3, specified licence was: unknown
-
-## class RBT::Installer
-
-This class was added in September 2022 and may eventually replace
-the old class RBT::Installer class. In December 2022 class
-RBT::Compile has been deprecated; class RBT::Installer is now
-the way to go, but RBT::Compile will be available for a somewhat
-longer time. Consider transitioning to RBT::Installer, though.
-
-class RBT::installer has been started from scratch. Note that for the time
-being RBT::Compile will co-exist with RBT::Installer; it may still
-receive bug fixes and other updates. But other than that,
-the code base in RBT::Installer should be better, and it may
-offer a greater functionality than does RBT::Compile - so in
-the long term (future), class RBT::Installer will become
-the new default. It will then be decided whether RBT::Compile
-will be retained or not after that.
-
-Note that RBT::Compile will be maintained for a longer time,
-so two ways to install something will co-exist. In the long
-run RBT::Installer will likely be better, but you may find
-it easier to use RBT::Compile instead for now.
-
-The rewritten class RBT::Installer has integrated various
-improvements. For instance, it is now possible to simply
-ignore compilation errors and other errors - this is
-sometimes necessary, because RBT erroneously reports
-some mistakes that are not real mistakes. The display
-and handling of messages has been improved in general -
-you can now decide to NOT read the extract-archive
-information, which used to be very spammy in the past.
-
-The flag --use-this-program-version is still available,
-but a new syntax has been added:
-
-    installer htop@3.1.2
-
-This may even work with locally existing archives.
+    RBT::Action::Installer: The licences do not match. Expected licence
+    RBT::Action::Installer: was: GPLv3, specified licence was: unknown
  
 ## The method RBT.filter_for_valid_program_names()
 
@@ -9480,7 +9485,7 @@ RBT suite may require such abbreviations, so it was
 easier to just bundle all these use cases into a single
 methods.
 
-I am making slow but steady progress with class RBT::Installer.
+I am making slow but steady progress with class RBT::Action::Installer.
 For instance, we can now install any different program
 version via the @ special syntax.
 
@@ -9502,9 +9507,9 @@ In the past the following syntax was used, with RBT::Compile:
 
 But this was quite verbose.
 
-For <b>RBT::Installer</b>, the above syntax will work
+For <b>RBT::Action::Installer</b>, the above syntax will work
 (eventually), but you can also use the @ syntax (which
-already does work, and was one reason why RBT::Installer
+already does work, and was one reason why RBT::Action::Installer
 has been written to begin with) like this:
 
     installer glib@2.72.3
@@ -9583,7 +9588,7 @@ I decided to pick option (2). Perhaps at a later time
 in the future this may be changed, and then this subsection
 will have to be updated, but for now I wanted to specify
 this behaviour and rationale here, when I was creating
-class RBT::Installer.
+class RBT::Action::Installer.
 
 ## class RBT::CreateLogFile
 
@@ -9591,7 +9596,7 @@ class RBT::Installer.
 log-related functionality of the RBT suite eventually.
 
 Right now in <b>September 2022</b> it is only used by class
-<b>RBT::Installer</b>, but in the long run it is expected to
+<b>RBT::Action::Installer</b>, but in the long run it is expected to
 handle all log-related aspects. The idea is that this
 class can be so flexible as to create all log files,
 including via .yml, that a user may want to look at
@@ -9700,12 +9705,12 @@ I added this functionality because I can not offhand
 remember the proper compile order, e. g. gst-plugins-bad,
 gst-plugins-ugly and so forth.
 
-## porg
+## Porg: the package organizer
 
 <b>Porg</b> is a small utility that allows a user to track which files
 are installed by a given program that is compiled from source. RBT
 supports the use of porg through a configuration file, called
-**use_porg.yml**. You can set its content to either true/false,
+<b>use_porg.yml</b>. You can set its content to either true/false,
 or yes/no - these are synonymous to one another. I prefer the
 yes/no nomenclature.
 
@@ -9719,6 +9724,11 @@ via:
 
     rbt porg --trad
 
+
+To query from the commandline whether porg will be used, use:
+
+    rbt --use_porg?
+
 The raw command for porg to run the make install step is like this:
 
     porg -lp htop-2.2.0 "make install"
@@ -9730,8 +9740,8 @@ via the rbt gem, like this:
 
 And you also have porg enabled.
 
-Then you can run the following on the commandline to let
-porg tell you which files were installed:
+Then you can run the following on the commandline to let porg tell you
+which files were installed:
 
     porg -f zlib
 
@@ -9784,12 +9794,12 @@ The software called <b>usbutils</b> depends on a header file called
 This header file (libusb.h) is part of <b>libusb</b>.
 
 So, if the user tries to compile usbutils, but the error reported
-refers to a missing libusb.h file, then the RBT::Installer class will
+refers to a missing libusb.h file, then the RBT::Action::Installer class will
 inform the user about this situation.
 
 This message may look like this:
 
-    RBT::Installer: You could consider compiling it via:
+    RBT::Action::Installer: You could consider compiling it via:
 
       rbt libusb
 
@@ -9812,88 +9822,6 @@ this functionality:
 
     RBT.simple_appdir_configure # ← simply pass arguments to this method.
 
-## class RBT::Installer
-
-The following subsection will explain the tasks handled by class
-RBT::Installer in more detail, as this is by far the most important
-class of the <b>rbt</b> gem.
-
-### Internals of class RBT::Installer
-
-**class RBT::Installer** is the main class of the RBT project, as it allows
-us to compile or install a program from source. It is, more or less, <b>the
-central entry point to RBT</b> - even though you can invoke the other .rb 
-files directly, RBT::Installer often provides a simpler convenience access
-to the disparate functions of the RBT project. It integrates other 
-classes, sort of like a <b>glue</b>.
-
-This subsection here will explain a few key decisions made, in the long
-run; and will also explain a few internals.
-
-Do not worry if this may be a bit confusing at first - it is meant
-primarily for me, and for others who may want to extend the RBT
-project one day.
-
-The method set_configure_base_directory(), defined in the file **misc.rb**,
-is used to determine the directory where the configure script ought to
-reside. That way we can enter a separate build directory yet still be
-able to invoke configure (or cmake) at the right directory target.
-
-### Commandline options for class RBT::Installer
-
-As was already written down somewhere else in this document, you
-can pass in several commandline options to class RBT::Installer.
-
-You can also use commandline options that include 
-<b>--</b> and these options can overrule other
-configure options, on an ad-hoc basis.
-
-For instance, let's assume that the configure options in a
-given yaml file, such as <b>weechat.yml</b>, include an
-option such as <b>--enable-gtk</b>. But you don't want
-any GTK GUI for Weechat. So either you modify the .yml
-file, or you decide to override this flag, on the
-commandline, by doing:
-
-    rbt weechat --disable-gtk
-
-This will now overrule the setting in the weechat.yml
-file for the given compilation run, and compile
-weechat with gtk <b>disabled</b>. That way you can
-leave weechat.yml unmodified, yet you are still
-able to get the desired change. (For a permanent
-change you would have to modify the .yml file of
-course.)
-
-If you want to get a quick overview, issue:
-
-    rbt --overview
-
-This should give a brief overview over
-the available utility scripts.
-
-### class RBT::Installer - the commandline option --compile-the-first-entry-in-the-current-working-directory
-
-On my computer system I have done the following alias:
-
-    this → rbt --compile-the-first-entry-in-the-current-working-directory
-
-So, I can then navigate to a directory containing a source archive
-that can be compiled. Then I type "this" and hit enter. RBT::Installer
-will proceed to compile the first entry of this directory.
-
-This allows me to be lazy and efficient. I will simply compile the first
-entry in any given directory, without having to type the name or even
-write the beginning of the name and use '*' as substitution character,
-such as via:
-
-    rbt php*.xz
-    rbt php*.xz
-
-I recommend that users of the rbt gem also use an alias such as "this",
-but of course this is up to them, not me. For me, personally, just
-typing "this" is very convenient should I need it.
-
 ## class RBT::WhatCouldBecomeAnAppDir
 
 class <b>RBT::WhatCouldBecomeAnAppDir</b> was added in March 2023. The idea
@@ -9979,13 +9907,7 @@ indicate the maintenance health of a project. Most will
 default to the value <b>actively maintained</b>, so this
 entry is primarily useful when a project was abandoned.
 
-## Defined actions in the RBT project
-
-<b>Defined actions</b> are actions that <b>always</b> "<i>stay the
-same</i>". They should be <b>reproducible</b>. They also should not
-require of the user of the RBT project to know the class-name or
-the file-name (of the .rb file that handles this task) as such
-whatsoever - this is a detail that is not necessary to know.
+## Defined actions in the RBT project and actions (actions tag)
 
 So, rather than think in terms of classes and .rb files, we think
 of every important part of RBT to be "actionable". That is, we can
@@ -10031,7 +9953,7 @@ alphabetically:
     :all_urls                                # Feedback/Show all remote URLs on the commandline.
     :appdir                                  # Compile the given program(s) at hand in a (versioned) appdir style.
     :autosymlink                             # This ad-hoc helper class can symlink from lib64/ to lib/. Rarely needed, though.
-    :autoupdate_this_program                 # Autoupdate a specific program. 
+    :autoupdate_this_program                 # Autoupdate a specific program.
     :batch_validate_the_cookbook_recipes     # Validate all cookbook recipes. This is not so important for regular users, though.
     :beautify_configure_help_output          # Beautify the "./configure --help" output.
     :binary_of                               # Query to which program a specific binary belongs to.
@@ -10048,26 +9970,31 @@ alphabetically:
     :compile_these_programs                  # Compile several programs one after the other, e. g. the batch-variant to the :compile_program action.
     :compile_the_python_addons               # Compile/Install all registered python add-ons (registered in the RBT suite that is)
     :cookbooks                               # Create a new instance of RBT::Cookbooks::SanitizeCookbook.
+    :copy_these_archives                     # Copy different source archives to the current working directory.
     :create_appdir_skeleton                  # Create a new AppDir skeleton structure for the given program.
     :create_cookbook_yaml_file               # Create a new .yml file for the given program.
     :create_log_directory                    # Create a new base log directory for the RBT project.
     :create_pkgconfig_file                   # This action will attempt to create a (pkgconfig) .pc file.
     :create_program_skeleton                 # Create a new AppDir skeleton for the given program. This is the same as ^^^ above, thus just another aliased name for it.
     :create_programs_version_html_file       # Create a large programs-version .html file. Not that useful for most end users, though.
-    :create_program_version_url_file         # This will create the default .md file containing all URLs, before the rbt gem is uploaded. Not that useful for most end users, though.
+    :create_program_version_url_file         # This will create the default .md file containing all URLs, before the rbt gem
+                                             # is uploaded. Not that useful for most end users, though.
     :create_programs_url_file                # This action will create the programs-URL file e. g. programs_version_url.md.
     :create_registered_tags                  # Create the registered-tags file. Normal users don't really need this.
     :create_snapcraft_file                   # Create a .snapcraft file for the given program.
-    :custom_toolchain                        # This action will compile as if the user passed the three options '--static --home-dir --do-not-symlink' to RBT::Installer.
+    :custom_toolchain                        # This action will compile as if the user passed the three options '--static --home-dir --do-not-symlink' to RBT::Action::Installer.
     :download                                # Download a specific source archive. Alias "aliased" to :rbt_download.
-    :download_all_source_archives            # Download all source archives, e. g. more than 3500 programs. Use only when you need to bootstrap your own local copy of archives.
+    :download_all_source_archives            # Download all source archives, e. g. more than 3800 programs. Use only when you need to bootstrap your own local copy of archives.
     :dual_compile                            # First compile the program at hand via /usr/ prefix, then again via an AppDir prefix.
     :extra_information                       # Show extra information about the given program at hand.
     :extract                                 # Extract a tarball/zip archive to some location.
-    :expand_cookbooks                        # This will expand from the short .yml files to the sanitized, longer .yml files, for all cookbooks.
+    :expand_cookbooks                        # This will expand from the short .yml files to the sanitized, longer
+                                             # .yml files, for all cookbooks. class ExpandCookbooks will handle this.
+    :expanded_cookbooks                      #
     :feedback_program_description            # This action will feedback the description of the given program at hand.
     :feedback_description_of                 # This action will feedback the description of the given program at hand - ^^^ similar to theabove.
-    :filter_for_valid_program_names          # Try to turn the given input into a required program, such as the input "ph" becoming "php".
+    :filter_for_valid_program_names          # Try to turn the given input into a required program, such as the input "ph"
+                                             # becoming "php" or "libar" becoming "libarchive".
     :find_all_archive_types                  # Find all local archives of a specific type, such as ".tar.gz".
     :find_url_for                            # Find the URL for a specific program, such as "htop".
     :generate_all_slack_desc_files           # Generate all slackware-description files for every registered program.
@@ -10087,6 +10014,7 @@ alphabetically:
     :parse_help                              # Parse the output that is yielded by issuing "./configure --help" normally, for configure-based programs.
     :paste_blfs                              # Simply show the BLFS entry of the given program. (It has to have such an entry, though, otherwise this will not work.)
     :query_file_association                  # This will query to which package a specific file belongs to (if it has been registered).
+    :remove_libtool_files                    # This action allows the user to remove .la files, in the versioned AppDir prefix
     :remove_outdated_archives                # This will remove outdated (that is old) archives, if more than one such archive exists locally.
     :remove_symlinks                         # This action will remove all broken symlinks (at the least in the PROGRAMS_DIRECTORY hierarchy).
     :rename_konsole_tab                      # This action will (try to) rename a konsole tab (that is KDE konsole), which is the terminal I tend to use.
@@ -10234,6 +10162,466 @@ This section here details them:
 
 MACRO read_file_as_pre_tag /home/x/programming/ruby/src/rbt/doc/statistics/n_classes_in_total_in_this_project.md
 
+
+
+
+## Build and compiling inside of a subdirectory (build directory)
+
+Sometimes you dont want to build in the current directory, but
+may want to use a subdirectory instead. (For example, glibc requires
+you to build inside a subdirectory).'
+
+To do this from the commandline, simply do one of the following
+commands:
+
+    rbt php --subdir=PHP_BUILD_DIRECTORY'
+
+The above would build in the directory called "PHP_BUILD_DIRECTORY".
+If this directory does not exist (which is the case usually), then 
+the RBT scripts will create that directory.'
+
+The default name for the subdirectory is called
+<b class="red">BUILD/</b> and you can do default to
+this directory:
+
+    rbt pango -b'
+
+This will create a <b class="red">BUILD/</b> directory and change 
+the working directory into it, while compiling.'
+
+In practise, defaulting to the BUILD/ directory is the easiest
+solution if you want to compile in your own directory.'
+
+Please also note that you can specify build directories
+in the respective cookbook file as well - look at the description
+of the variables called `<span class="yel">use_build_directory</span>`, 
+and `<span class="yel">use_this_build_directory</span>`.'
+
+Alternative syntax exists as well,of course. If you want to
+use the default build directory for a project you compile, you
+can pass the option <b>usebuilddir</b> like so.'
+
+    rbt automake --use-build-dir'
+    rbt automake usebuilddir'
+    rbt htop usebuilddir'
+    rbt php use_build_dir'
+
+You can also specify a specific build directory to use.'
+
+One way that this works is via this:
+
+    rbt htop --use-this-build-dir=/Depot/j'
+
+The RBT scripts will append a trailing / if it is a
+directory and if it does not yet have a trailing / character
+presently, so the above command is the very same as passing
+in <b>/Depot/j/</b>.'
+
+If you want to use a build directory, but do not care
+about the name, you can also use a random name, like 
+so:
+
+    rbt php --use-random-build-directory'
+
+## class RBT::Action::Installer
+
+This extremely important class was added in September 2022 and has
+replaced the older class called <b>RBT::Compile</b>. In December 2022
+class RBT::Compile has been deprecated, and in 2024 removed completely;
+class RBT::Action::Installer is now the way to go. RBT::Compile
+is no longer available.
+
+class RBT::Action::Installer has been started from scratch. Note that for the time
+being RBT::Compile will co-exist with RBT::Action::Installer; it may still
+receive bug fixes and other updates. But other than that,
+the code base in RBT::Action::Installer should be better, and it may
+offer a greater functionality than does RBT::Compile - so in
+the long term (future), class RBT::Action::Installer will become
+the new default. It will then be decided whether RBT::Compile
+will be retained or not after that.
+
+Note that RBT::Compile will be maintained for a longer time,
+so two ways to install something will co-exist. In the long
+run RBT::Action::Installer will likely be better, but you may find
+it easier to use RBT::Compile instead for now.
+
+The rewritten class RBT::Action::Installer has integrated various
+improvements. For instance, it is now possible to simply
+ignore compilation errors and other errors - this is
+sometimes necessary, because RBT erroneously reports
+some mistakes that are not real mistakes. The display
+and handling of messages has been improved in general -
+you can now decide to NOT read the extract-archive
+information, which used to be very spammy in the past.
+
+The flag --use-this-program-version is still available,
+but a new syntax has been added:
+
+    installer htop@3.1.2
+
+This may even work with locally existing archives.
+
+The following subsections will explain the tasks handled by
+class RBT::Action::Installer in more detail, as this is by
+far the most important class of the <b>rbt</b> gem. This is
+ongoing - right now many details are not yet explained, so
+the following subsections will eventually be expanded.
+
+### Internals of class RBT::Action::Installer
+
+<b>class RBT::Action::Installer</b> is the main class of the RBT project, as it allows
+us to compile or install a program from source. It is, more or less, <b>the
+central entry point to RBT</b> - even though you can invoke the other .rb 
+files directly, RBT::Action::Installer often provides a simpler convenience access
+to the disparate functions of the RBT project. It integrates other 
+classes, sort of like a <b>glue</b>.
+
+This subsection here will explain a few key decisions made, in the long
+run; and will also explain a few internals.
+
+Do not worry if this may be a bit confusing at first - it is meant
+primarily for me, and for others who may want to extend the RBT
+project one day.
+
+The method set_configure_base_directory(), defined in the file **misc.rb**,
+is used to determine the directory where the configure script ought to
+reside. That way we can enter a separate build directory yet still be
+able to invoke configure (or cmake) at the right directory target.
+
+### Commandline options for class RBT::Action::Installer
+
+As was already written down somewhere else in this document, you
+can pass in several commandline options to class RBT::Action::Installer.
+
+You can also use commandline options that include 
+<b>--</b> and these options can overrule other
+configure options, on an ad-hoc basis.
+
+For instance, let's assume that the configure options in a
+given yaml file, such as <b>weechat.yml</b>, include an
+option such as <b>--enable-gtk</b>. But you don't want
+any GTK GUI for Weechat. So either you modify the .yml
+file, or you decide to override this flag, on the
+commandline, by doing:
+
+    rbt weechat --disable-gtk
+
+This will now overrule the setting in the weechat.yml
+file for the given compilation run, and compile
+weechat with gtk <b>disabled</b>. That way you can
+leave weechat.yml unmodified, yet you are still
+able to get the desired change. (For a permanent
+change you would have to modify the .yml file of
+course.)
+
+If you want to get a quick overview, issue:
+
+    rbt --overview
+
+This should give a brief overview over
+the available utility scripts.
+
+### class RBT::Action::Installer - the commandline option --compile-the-first-entry-in-the-current-working-directory
+
+On my computer system I have done the following alias:
+
+    this → rbt --compile-the-first-entry-in-the-current-working-directory
+
+So, I can then navigate to a directory containing a source archive
+that can be compiled. Then I type "this" and hit enter. RBT::Action::Installer
+will proceed to compile the first entry of this directory.
+
+This allows me to be lazy and efficient. I will simply compile the first
+entry in any given directory, without having to type the name or even
+write the beginning of the name and use '*' as substitution character,
+such as via:
+
+    rbt php*.xz
+    rbt php*.xz
+
+I recommend that users of the rbt gem also use an alias such as "this",
+but of course this is up to them, not me. For me, personally, just
+typing "this" is very convenient should I need it.
+
+## class RBT::Action::Installer: feedback the URL of various programs at the same time
+
+Say that you want to find out the URL to various programs at the same
+time.
+
+You can use this:
+
+    rbt --url-for-these-programs=php,ruby,python,m4,php
+
+This will show a result such as:
+
+<img src="https://i.imgur.com/F9yA9vr.png" style="margin: 1em">
+
+Entries that are included more than once - such as php in the above
+made-up example - will only be shown once.
+
+## BLFS - Beyond Linux From Scratch (and also LFS)
+
+<b>class RBT::Blfs</b> has "support" for BLFS in that it will ... simply
+show a URL to the remote BLFS page of a given package, if it exists,
+on the commandline.
+
+If you only need to know the URL to the <b>BLFS homepage</b>, to embed
+it for display into a webpage perhaps or to merely display it onto the
+commandline, you can use the following simple <b>toplevel-API</b> for
+this:
+
+    RBT.blfs(:name_of_the_program_goes_in_here)
+    RBT.blfs(:openssl) # => "https://www.linuxfromscratch.org/blfs/view/8.1/postlfs/openssl.html"
+
+    # You can also use a String as input to the method rather than a Symbol:
+    RBT.blfs('ruby') # => "https://www.linuxfromscratch.org/blfs/view/svn/general/ruby.html"
+
+This will return the remote BLFS page, as URL (a **String**, actually),
+if it exists, and if it has been registered in the corresponding 
+.yml file (cookbook file for the program at hand; in this example
+the file <b>openssl.yml</b>). If no BLFS entry has been registered
+then **nil** will be returned by this method.
+
+You can also use class <b>RBT::LFS</b> to build/create a LFS from scratch.
+This is presently (as of the year <b>2019</b>) quite incomplete, though,
+and will not work. Lots of different things have to be done in the correct
+sequence before a LFS can be built from scratch successfully, and possible
+errors have to be checked before the build can continue. In the long run,
+for the future, this will eventually work, one day - but for now it is an
+incomplete stub and not recommended for testing much at all. It is simpler
+to use the slow, semi-manual approach for now.
+
+If you wish to quickly <b>paste</b> the BLFS page of a given program onto
+the commandline, for display purpose, then you can do something like this:
+
+    rbt php --parseblfs
+
+Since as of <b>September 2021</b> a bin/ script exists for this functionality.
+This was already planned back in <b>August 2019</b>, but I finally had a 
+good use case (support for my older laptop) to add it. The executable
+is called <b>paste_blfs</b> and it can be used in the following way
+via the <b>commandline</b>:
+
+    paste_blfs ruby
+    paste_blfs htop
+
+Since as of <b>December 2019</b>, it is now also possible to display,
+on the commandline, <b>any</b> registered BLFS entry. This will help
+in the event that you can not access the xorg-server at the moment,
+yet still require information for different packages (I faced
+exactly this problem, so I then added that functionality to RBT).
+
+In order for this to work, you evidently need to have a working
+**internet connection** available - but in principle, the information
+stored in the BLFS project could be zipped up and distributed
+too, within the RBT project.
+
+For the time being, though, only pasting is supported - there is
+no plan to bundle the information into the RBT project at this
+stage in time.
+
+Usage example for this functionality:
+
+    rbt --parse-blfs-page-for=llvm
+
+In <b>December 2019</b> another feature was added - the ability to
+make use of the BLFS instructions directly, and run them.
+
+The idea here is that you may wish to compile some program
+from source, but may not access a working xorg-server, as
+you are working on the commandline only.
+
+Invocation example:
+
+    rbt kerberos --use-blfs-instructions # Compile kerberos in the BLFS way.
+
+Since LFS/BLFS is such a useful project, the RBT suite has some
+more support in this regard. This is unsurprising, as the
+<b>Linux From Scratch</b> (LFS) Project has instructions
+on how to compile programs from source. So it has a somehwat
+similar meta-goal, like RBT.
+
+These instructions are immensely useful. A lot of the information
+from LFS/BLFS was integrated into the RBT project.
+
+Many individual cookbook yaml files can point towards the
+LFS/BLFS page, which will often contain additional useful
+information in case you get stuck with something.
+
+You can try to show this URL by doing this:
+
+    blfs curl
+
+This would show the BLFS remote URL of the program called
+<b>curl</b>.
+
+Since as of <b>July 2017</b>, you can also directly paste the
+content of the remote BLFS webpage onto the terminal, if there
+is a remote BLFS page associated with a given program.
+
+The way to do this is as follows:
+
+    rbt gcc --paste-blfs-page
+
+If you want to show all programs that have a blfs entry, use the
+following command:
+
+    rbt --show-programs-with-a-blfs-entry
+
+If you want to obtain an Array of all programs containing
+a BLFS entry, you can use the following toplevel API:
+
+    RBT.return_all_blfs_entries
+
+This is currently rather slow; I'll look into making it
+faster in the future, making use of grep.
+
+If you want to find out how many BLFS entries are registered,
+use this toplevel method:
+
+    RBT.n_BLFS_entries?
+    
+## Licence of this project
+
+Now to some semi-boring legalese, aka the "no warrant disclaimer" in particular.
+
+Forst, the copyright notice:
+
+Copyright 2010-2024 Robert A. Heiler
+
+Up until the beginning of <b>April 2021</b>, the rbt project was using the
+<b>GPL-2.0 licence</b> (no later clause).
+
+In <b>April 2021</b>, though, I decided to switch to the <b>MIT</b> licence
+instead for this project. The older GPL code will remain available for some
+time, most likely at the least a full year, perhaps even longer. But the
+older code is now deprecated as far as I am concerned; others would have to
+maintain it. I only focus on the MIT variant from this point onward.
+
+You can read up on the MIT licence here:
+
+https://opensource.org/licenses/MIT
+
+To make it even more explicit, let me additionally formulate
+the no-warranty disclaimer:
+
+The source code is <b>provided as is</b>. No explicit
+guarantees are given of any kind whatsoever.
+
+Whenever possible, bugs will be fixed. However had, do
+not expect there to be no bugs in this software suite.
+Chances should be fairly high that it will run on
+your system.
+
+Why was it decided to switch to MIT rather than GPL?
+
+Well, there are several reasons.
+
+First, and most importantly: while I will continue to maintain the project
+here for a long while (I am using it on a daily basis after all), it is not
+really a project I particular "care" about in the sense of wanting to
+restrict how users use it. It is just a ruby gem, not anything I am using
+for a "mission-critical project". It also is not important to me in regards
+to my financial status; nothing against donation by interested folks, but I
+did not create the project for any of that. I created the project mostly
+because I needed to compile software or otherwise install software.
+
+Second, though, the GPL is a strict licence. This can be very
+useful - see the Linux Kernel. You may also depend less on 
+corporations controlling the whole software stack, so the GPL
+has quite laudable goals. But ... is the GPL really important
+for a project like this one here? I am not sure. I think you
+can already "generate value" if a project is useful, so the 
+licence then is of a secondary concern, in particular when
+it is a smaller project anyway.
+
+These were my two main reasons. There are a few smaller issues,
+such as the MIT licence being <b>much</b> simpler to use and
+adhere to, but by and large these were the main reasons.
+
+And if a company ever decides to want to make use of RBT
+then I feel flattered, anyway - it means that the project
+has some real value after all, right? Otherwise people
+would not use it.
+
+Be wary of bugs, though; even the MIT licence comes with a
+"no warranty" clause, so always test things first in a
+secure environment (chrooted jail environment, for instance,
+then you can copy or package the compiled packages to 
+wherever you need them(.
+
+While I use this project since over a decade, my use cases
+may not be the same as how other people use the project.
+
+Take note that the rbt-gem erroneously had <b>GPL-2.0</b> as
+its licence in the last some months (in 2023). This
+was a manual error on my behalf, due to rubygems
+showing a warning on the commandline about "unspecified
+licences". I am not sure why I changed to GPL-2.0 as
+a result; perhaps I was working on another project that
+was GPL-2.0 licenced and confused the two. Either way when 
+the rbt gem was rewritten in the year 2024, this was again
+fixed and the MIT licence was reinstated here - apologies
+for any confusion in this regard, it was supposed
+to be MIT licenced.
+
+## RBT::Gitty
+
+class RBT::Gitty is a helper class. It ultimately wraps over
+the "--gitty" that RBT::Installer uses.
+
+The RBT::Gitty class can be used to quickly checkout the
+git sources of a project.
+
+So, for instance, if you want to check out the latest
+source code of mesa, you could do this via the commandline:
+
+    gitty mesa
+
+This will download mesa and repackage it to today's
+timestamp, in dd.mm.yyyy notation.
+
+You can download any program that is registered in the
+RBT namespace, if it has a corresponding entry called
+<b>git_url</b> in the .yml file. This is how I maintain
+this list: I simply change the associated git URL,
+such as for github or gitlab, in the corresponding
+.yml file.
+
+Since as of March 2024 gitty was slightly extended, in
+that it can now work on any arbitrary remote URL that
+you pass into this class.
+
+For instance:
+
+    gitty https://github.com/kennylevinsen/seatd
+
+This would download the current git sources from
+that remote URL, and repackage it automatically
+for you, using a dd.mm.yyyy notation. This functionality
+was added because I sometimes found new programs and
+just wanted to quickly test whether I can compile it,
+so I can now just copy/paste this URL onto the
+commandline, as input for <b>gitty</b>.
+
+## RBT::Action::SoftwareManager
+
+class RBT::Action::SoftwareManager was added in March 2024. It
+will eventually replace class Installer. The key idea behind
+SoftwareManager, aside from fixing a few smaller bugs and
+issues, will be to transition into an action-based system.
+This means that everything that is important, to be done
+by class SoftwareManager, should be handled through
+the method called <b>RBT.action()</b> primarily.
+
+The advantage of this approach is that we can easily change
+aspects of class SoftwareManager, without having to 
+modify the class directly.
+
+This replacement effort may take quite a while, though. For
+now, class Installer will remain in place and is still
+the preferred variant to be used.
+
 ## Available programs versions
 
 MACRO read_file_as_pre_tag /home/x/programming/ruby/src/rbt/lib/rbt/yaml/programs_version/available_programs_versions.md
@@ -10242,15 +10630,17 @@ DONATE_MACRO
 
 ## Feedback wanted and appreciated, as well as contributions to the RBT project
 
-Please consider providing <b>feedback</b> about rbt, whether you
-found anything useful in it, whether there are some bugs or other
-problems, and suggestions to improve the project.
+<b>Feedback</b> about rbt will be considered, in particular to make working
+with it easier and better. Suggestions to improve the project are also welcome,
+in particular if it comes to smaller changes, as they are easier to implement.
 
-Especially appreciated are new ideas about new
-or missing features and functionality.
+New ideas about new or missing features and functionality are appreciated as
+well.
 
-Code contribution of all sorts are also desired. Please try
-to adhere to the coding standard(s) though - at the least 
-document new code extensively.
+Code contribution of all sorts are also accepted. Please try to adhere to
+the coding standard(s) though - at the least document any new code
+that is to be added extensively, so that other users (as well as I)
+understand what the code does. I may add a github project tracker for
+ideas pertaining this.
 
 ADD_CONTACT_INFORMATION