rbt 0.11.118 → 0.13.42

data/doc/README.gen

@@ -1,5 +1,5 @@
 [![logo](https://i.imgur.com/QAAheRP.png)](https://rubygems.org/gems/rbt)
-[![logo](http://shevy.bplaced.net/COOKBOOKS_LOGO.png)](https://rubygems.org/gems/rbt)
+[![logo](https://i.imgur.com/LiwQlUB.png)](https://rubygems.org/gems/rbt)
 
 DEFAULT_HEADER
 
@@ -21,7 +21,7 @@ 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.
+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>
@@ -31,6 +31,13 @@ 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
@@ -367,7 +374,6 @@ 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?
@@ -421,16 +427,13 @@ 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>.
 
+It is a smaller release compared to the 0.11.x series.
 
-
-
-## Most recent release series (some kind of "changelog" entry)
-
-The most recent release series, which is <b>version 0.11.x</b>,
-has been (mostly) rewritten from scratch for at the least the
-following <b>five reasons</b>:
+The reasons for releasing version 0.11.x were:
 
 - I needed to add support to compile from source, via
 a sqlite-database. Hence class RBT::CompileViaSQLDatabase
@@ -460,6 +463,65 @@ software.
 - Extend all actions. That is, note down everything in the
 RBT suite that can be done via such actions.
 
+For version 0.12.x the primary change was to simply
+remove class RBT::Compile. Use class RBT::Installer instead.
+
+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.
+
+## 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?
+
+Well - there are various big classes, such as class RBT::Installer.
+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.
+
+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.
+
+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
+to capture ALL actionable events through a unified handler - in
+this case 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
+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
+through a file called config.log. I don't like that. I want
+error messages to be instantly useful, or even be resolved
+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
+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 
+automatically update a computer from zero-to-hero, without
+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
+those actionable callbacks. So, one distant future, 
+class RBT::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.
+
 ## Conventions and Aliases used for the purpose of this document as well as the RBT project in general
 
 Commands that you can typically use on the commandline, such as
@@ -4727,11 +4789,12 @@ is very important.
 
 ## Flexbox
 
-Until November 2019, the RBT project had **class RBT::Infobox**. This
-was moved into the AsciiParadise project in November 2019, and renamed
-to **Flexbox**.
+Until November 2019, the RBT project had <b>class RBT::Infobox</b>. This
+was moved into the <b>AsciiParadise project</b> in November 2019, and
+renamed to <b>Flexbox</b>.
 
-Let's have a look how the new Flexbox looks, on the commandline:
+Let's next have a look how the new Flexbox looks, on the
+<b>commandline</b>:
 
 <img src="https://i.imgur.com/NwC33Gu.png" style="margin: 1em">
 
@@ -5706,7 +5769,7 @@ dependencies.
 
 ## RBT::Linux::RenameSystemMap
 
-class **RBT::Linux::RenameSystemMap** can be used to quickly
+class <b>RBT::Linux::RenameSystemMap</b> can be used to quickly
 rename the /boot/System.map file. It is probably not very
 useful to most folks, but I needed this as part of the effort
 to do an automated build for LFS/BLFS.
@@ -6166,7 +6229,7 @@ program.
 
 Sometimes this may lead to unexpected or unwanted results,
 though, such as when you want to compile program **a**, but
-the **rbt project** renames the program to **b** instead.
+the <b>rbt project</b> renames the program to <b>b</b> instead.
 
 In order to avoid this, a commandline-option exists for
 the RBT project that specifically disallows this from
@@ -6549,40 +6612,6 @@ Example:
 
   ry libgpgerror --dir64
 
-## Static compilation
-
-Some programs can be compiled statically, but this may also lead
-to problems sometimes - such as when the program can <b>NOT</b>
-be compiled statically.
-
-The optional entry **build_static** in a cookbook file allows
-us to determine whether compilation should be statically or
-whether it should not be static.
-
-If you wish to overrule this on the commandline and specifically
-**disable** static compilation, you can use a commandline 
-instructions such as:
-
-    rbt htop --do-not-build-statically
-
-Note that as of **December 2018** you can also combine
---enable-shared --disable-static in one variant via:
-
-    rbt libxmu --shared-no-static ntrad
-
-To determine whether a program can be compiled statically, you can
-issue a command such as the following:
-
-    rbt tar --can-be-compiled-statically?
-
-Do note that this requires a manual registration in the corresponding
-yaml file; by default this will return false (aka no).
-
-Since as of July 2020 you can also determine which programs can
-be compiled statically in general, via:
-
-    rbt --which-programs-can-be-compiled-statically?
-
 ## Disable adding the shell script error line
 
 By default, the configure scripts will try to make use of
@@ -8355,14 +8384,14 @@ For more documentation, have a look at
 
 ## Tab-Completion support for various shells
 
-**Tab completion** support exists for some of the commands, for **bash**,
+<b>Tab completion</b> support exists for some of the commands, for **bash**,
 **zsh** and **fish**. These are completions that can be invoked when
 the user hits the <b>tab-key</b> on the keyboard.
 
 In order for this to work, the corresponding file has to be sourced
 (loaded).
 
-For **RBT**, making use of tab-completion can simplify compilation.
+For <b>RBT</b>, making use of tab-completion can simplify compilation.
 Simply type "rbt", followed by a space, and then the first character
 of the program that you wish to install, followed by hitting the
 **TAB** key. (Do not forget to source the generated file in your
@@ -8798,218 +8827,6 @@ of a given program. As you can see, the number of registered
 (and thus tracked) programs increases steadily, as more and
 more programs are added.
 
-## 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.
-
-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 call its "action", which will lead to
-its specified, designated effect, such as compiling a 
-program from a remote URL.
-
-Thus, we should also provide a **unified topdown way**
-how to call <b>all</b> these actions. Furthermore we
-can <b>chain</b> these actions, to achieve a combined,
-new effect. For instance, in order to compile a program
-from source, we have to do certain actions one after the
-other. Thus we can specify all of them via these
-actions. 
-
-The general syntax suggestion for such an <b>action</b>
-is as follows:
-
-    RBT.action(:create_program_skeleton, 'htop-1.2')
-
-This would be the very same as issuing:
-
-    rcp htop-1.2
-
-From the commandline.
-
-The reason why I think adding support for this is useful is because once
-you have many individual tasks in the project, it gets messy to remember
-their names and remember where that action resides (in which particular
-.rb file and class). Whereas, if we use a Symbol such as the above, we can
-call this from any other .rb file as-is, and have that work, without having
-to think about which specific .rb file to call, and so forth. Extra
-actions can be passed via {} blocks in a generic way, so this should
-be quite flexible if the user requires fine-tuning of this.
-
-I will keep on exploring this - in the long run, the goal would be to
-make all **actions** available via the above generic API call.
-Furthermore we can also alias this, to simplify calling it from
-within ruby code.
-
-The following actions are registered as of **May 2022**, sorted
-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. 
-    :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.
-    :blfs                                    # Show the BLFS entry of the given program. This only works if there is a registered BLFS entry for the given .yml file.
-    :build_detector                          # The build detector can be used to determine whether a program uses "configure" or "cmake" or "meson" and so forth.
-    :chainer                                 # Chain-compile a series of programs, such as the "KDE5 applications".
-    :chroot_compile                          # Compile into a chrooted environment as prefix-target.
-    :colour_make                             # Run "make" in a colourized manner, that is, with colour support.
-    :colour_make_install                     # Run "make install" in a colourized manner, that is, with colour support.
-    :compile_in_traditional_manner           # This will compile the passed programs via the /usr/ prefix.
-    :compile_into_home_dir                   # This will compile the given program into the HOME directory of the user, e. g. /root/ for the superuser.
-    :compile_program                         # Compile a specific program. Symbols exist for shortcuts such as :lfs1.
-    :compile_strategies                      # Give an overview over the available compile-strategies in use.
-    :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.
-    :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_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.
-    :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.
-    :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.
-    :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".
-    :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.
-    :generate_version_file                   # Generate the large programs_version.yml file.
-    :highest                                 # Show the "largest" programs, that is, the biggest file archives stored locally.
-    :home_dir_without_symlinking             # Compile into the home directory, such as /root/, but do not symlink afterwards.
-    :homepage                                # Simply report the homepage of the given argument, e. g. RBT.action(:homepage, 'php').
-                                             # :report_the_homepage is an alias to :homepage, by the way.
-    :install_this_rubygem                    # To quickly install a rubygem .gem file
-    :libtool                                 # A wrapper over libtool, to try to make libtool suck less.
-    :make                                    # A wrapper over "make", primarily done to add colour support when doing "make" on the commandline.
-    :make_app_prefix                         # Run "make" but pass an explicit app-dir prefix towards it.
-    :manual_steps                            # (Missing description right now.)
-    :meson_appdir_prefix                     # Compile via a meson-based system, into the default appdir prefix (e. g. /Programs/Htop/3.1.2/ or a siilar prefix).
-    :multi_url_displayer                     # This will show several URLs in one go, such as for "lxqt".
-    :ntrad                                   # Compile in an AppDir manner.
-    :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_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.
-    :report_how_many_binaries_are_registered # Report how many binaries are registered in the RBT project.
-    :report_host_cpu                         # Report the host CPU in use, such as "x86_64".
-    :report_the_mate_desktop_version         # Report the mate-desktop version, on the commandline.
-    :report_total_size_of_all_archives       # Report the total size of all local archives.
-    :report_xfce_version                     # Report the XFCE version (if installed locally).
-    :run_make_then_make_install              # This will first run "make" and then "make install". It is mostly a convenience method, with support for colours.
-    :scookie                                 # Show a lot of information about a specific program.
-    :search_for_tags                         # Search for all programs that have a specific tag.
-    :show_all_about                          # Show all about a specific program, e. g. "htop".
-    :show_compile_chain                      # Show the compile chain for the given program.
-    :show_configuration_options              # Show the configuration options of a specific program, if it has any.
-    :show_versions_of_these_programs         # Show versions of the given programs.
-    :simple_appdir_configure                 # Compile a program via an app-dir prefix, e. g. /Programs/Htop/1.2.3/.
-    :store_abbreviations                     # This will store all abbreviations to the registered program names.
-    :suggest_cookbook_for                    # Suggest a cookbook for a specific program, such as "htop".
-    :symlink_into_the_usr_bin_hierarchy      # Symlink the given Array into the /usr/bin/ hierarchy.
-    :test_this_alias                         # Test whether the input is an alias to a program, such as "ht" towards "htop".
-    :to_current                              # Create a "Current" symlink.
-    :toolchain                               # This will attempt to build a standalone toolchain for compilation, similar to what LFS does.
-    :trad                                    # Compile a program in the traditional manner, aka prefix /usr/. The symbol :traditional is an "alias" to this entry point.
-    :uchroot_chompile                        # Compile via user-chroot prefix.
-    :url_action                              # Support instructions such as /install/php/6.3.1, in particular for www-related use cases.
-    :update_all_ruby_gems                    # This will update all ruby .gem files that are registered in the RBT project.
-    :update_entry                            # Update a specific program-entry, into the corresponding .yml file.
-    :update_kde_application                  # Update all KDE applications (kde apps).
-    :update_tags                             # This will update all registered tags.
-
-So, when you want to invoke :update_kde_application then you can simply
-do this:
-
-    RBT.action(:update_kde_application)
-
-(Note that <b>RBT.actions()</b> is an alias to RBT.action(). Internally the
-RBT project will default to <b>RBT.action()</b> only, though; <b>RBT.actions()</b>
-exists mostly as a convenience-alias for e. g. working with IRB, if you
-forget the API, e. g. plural or singular - both will work.)
-
-In **February 2022** a **new filter-method** was added that can be applied
-to turn a given input argument into a "registered" program. What this
-is meant to imply is that, say, you pass in the argument **htop.yml**.
-The .yml part is superfluous, so that filter-method would turn **htop.yml**
-into **htop**. This is not the only modification that is done there;
-the more important take-home message is that the end user shall never
-have to wonder about any of this. The rbt project will try to make
-sense of the given input at hand, as much as that is possible.
-
-More actions will be added as time permits. There is a secondary advantage
-when using actions, by the way. **If** an action is specified, such as
-via Symbols, then we can internally change which class and .rb file
-handles that action. So perhaps we have some bugs and fixing these
-takes too long, but we still want the specified action to work - in
-this event we could quickly write a small task that handles the
-specified action, without having to worry about side effects.
-
-Note that the above overview does **not** include all available 
-actions; some are mostly internal actions that have very little
-value for regular users.
-
-The actions may be a bit verbose and not necessarily easy to
-read compared to a method.
-
-Consider the following:
-
-    RBT.action(:install_this_rubygem, 'path_to_the.gem')
-    RBT.action(:install_this_rubygem, '/tmp/thor-1.2.0.gem')
-
-This would install this rubygem, if it exists locally, e. g.
-the <b>thor</b>-gem.
-
-Now compare this to this toplevel method:
-
-    RBT.install_this_rubygem('/tmp/thor-1.2.0.gem')
-
-The second variant is a bit shorter and easier to read, in
-my opinion. So it is the better variant, yes?
-
-Well, it depends. Brevity is useful, but think about the
-benefit you get via RBT.action(): you can simply call
-one unified method (e. g. action()) to do the required
-action. And we can add lots of aliases to this, to 
-make working with it easier. And you don't have to 
-worry about **where** the code resides - you just
-use the action without a need to do any manual require
-call.
-
-I think if you think this through for a while then you may
-realise that RBT.action() is not such a bad idea - it
-provides <b>actionable</b> entry points to the whole
-RBT suite.
-
-Since as of <b>September 2022</b> all executables that
-are part of the RBT suite, under the bin/ subdirectory,
-are "actionable". That is they are implemented via
-<b>RBT.action()</b> calls. New executables will conform
-to this new default. The only two exceptions are bin/rbt
-and bin/rbt_config - these two will not use RBT.action().
-But who knows - perhaps at some point in time in the
-future they may.
-
 ## Different datasets
 
 The first, raw material for the dataset is a fairly short .yml
@@ -10089,6 +9906,319 @@ can be compiled into an AppDir.
 This may be a bit confusing for newcomers, so this is clearly something
 for advanced users only.
 
+## Show the manual installation steps
+
+If you want to see the manual installation steps, use the file
+show_manual_steps.rb.
+
+This will not invoke these steps, contrary to another class which
+will invoke the manual steps.
+
+
+## Static compilation
+
+Some programs can be <b>compiled statically</b>, but this may also lead
+to problems sometimes - such as when the program can <b>NOT</b> be
+compiled statically.
+
+The optional entry **build_static** in a cookbook file allows us to
+determine whether compilation should be statically or
+whether it should not be static.
+
+If you wish to overrule this on the commandline and specifically
+**disable** static compilation, you can use a commandline 
+instructions such as:
+
+    rbt htop --do-not-build-statically
+
+Note that as of **December 2018** you can also combine
+--enable-shared --disable-static in one variant via
+<b>--shared-no-static</b>:
+
+    rbt libxmu --shared-no-static ntrad
+
+To determine whether a program can be compiled statically, you can
+issue a command such as the following:
+
+    rbt tar --can-be-compiled-statically?
+
+Do note that this requires a manual registration in the corresponding
+yaml file; by default this will return false (aka no).
+
+Since as of July 2020 you can also determine which programs can
+be compiled statically in general, via:
+
+    rbt --which-programs-can-be-compiled-statically?
+
+Next, a few words about statically compiled binaries on Linux. I added
+this subsection in 2023 because I sometimes need to remember how to
+do so without the rbt project.
+
+I found that often setting CFLAGS to include -static works.
+
+In ruby this would look like this:
+
+    ENV['CFLAGS'] = ENV['CFLAGS']+' -static -g'
+
+I tested this on the program called <b>sed</b> in June 2023, and,
+indeed, the resulting binary was statically compiled. \o/
+
+## The entry status_of_the_project in a cookbooks .yml file
+
+In June 2023 the entry <b>status_of_the_project</b> was added.
+
+Possible values include:
+
+    - outdated
+    - possibly outdated
+    - low maintenance
+    - actively maintained
+
+This is somewhat experimental for now. The key idea is to
+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.
+
+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
+call its "action", which will lead to its specified, designated
+effect, such as compiling a program from a remote URL.
+
+Thus, we should also provide a <b>unified topdown way</b>
+how to call <b>all</b> these actions. Furthermore we
+can <b>chain</b> these actions, to achieve a combined,
+new effect. For instance, in order to compile a program
+from source, we have to do certain actions one after the
+other. Thus we can specify all of them via these
+actions. 
+
+The general syntax suggestion for such an <b>action</b>
+is as follows:
+
+    RBT.action(:create_program_skeleton, 'htop-1.2')
+
+This would be the very same as issuing:
+
+    rcp htop-1.2
+
+From the commandline.
+
+The reason why I think adding support for this is useful is because once
+you have many individual tasks in the project, it gets messy to remember
+their names and remember where that action resides (in which particular
+.rb file and class). Whereas, if we use a Symbol such as the above, we can
+call this from any other .rb file as-is, and have that work, without having
+to think about which specific .rb file to call, and so forth. Extra
+actions can be passed via {} blocks in a generic way, so this should
+be quite flexible if the user requires fine-tuning of this.
+
+I will keep on exploring this - in the long run, the goal would be to
+make all **actions** available via the above generic API call.
+Furthermore we can also alias this, to simplify calling it from
+within ruby code.
+
+The following actions are registered as of **May 2022**, sorted
+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. 
+    :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.
+    :blfs                                    # Show the BLFS entry of the given program. This only works if there is a registered BLFS entry for the given .yml file.
+    :build_detector                          # The build detector can be used to determine whether a program uses "configure" or "cmake" or "meson" and so forth.
+    :chainer                                 # Chain-compile a series of programs, such as the "KDE5 applications".
+    :chroot_compile                          # Compile into a chrooted environment as prefix-target.
+    :colour_make                             # Run "make" in a colourized manner, that is, with colour support.
+    :colour_make_install                     # Run "make install" in a colourized manner, that is, with colour support.
+    :compile_in_traditional_manner           # This will compile the passed programs via the /usr/ prefix.
+    :compile_into_home_dir                   # This will compile the given program into the HOME directory of the user, e. g. /root/ for the superuser.
+    :compile_program                         # Compile a specific program. Symbols exist for shortcuts such as :lfs1.
+    :compile_strategies                      # Give an overview over the available compile-strategies in use.
+    :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.
+    :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_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.
+    :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.
+    :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.
+    :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".
+    :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.
+    :generate_version_file                   # Generate the large programs_version.yml file.
+    :highest                                 # Show the "largest" programs, that is, the biggest file archives stored locally.
+    :home_dir_without_symlinking             # Compile into the home directory, such as /root/, but do not symlink afterwards.
+    :homepage                                # Simply report the homepage of the given argument, e. g. RBT.action(:homepage, 'php').
+                                             # :report_the_homepage is an alias to :homepage, by the way.
+    :install_this_rubygem                    # To quickly install a rubygem .gem file
+    :libtool                                 # A wrapper over libtool, to try to make libtool suck less.
+    :make                                    # A wrapper over "make", primarily done to add colour support when doing "make" on the commandline.
+    :make_app_prefix                         # Run "make" but pass an explicit app-dir prefix towards it.
+    :manual_steps                            # (Missing description right now.)
+    :meson_appdir_prefix                     # Compile via a meson-based system, into the default appdir prefix (e. g. /Programs/Htop/3.1.2/ or a siilar prefix).
+    :multi_url_displayer                     # This will show several URLs in one go, such as for "lxqt".
+    :ntrad                                   # Compile in an AppDir manner.
+    :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_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.
+    :report_how_many_binaries_are_registered # Report how many binaries are registered in the RBT project.
+    :report_host_cpu                         # Report the host CPU in use, such as "x86_64".
+    :report_the_mate_desktop_version         # Report the mate-desktop version, on the commandline.
+    :report_total_size_of_all_archives       # Report the total size of all local archives.
+    :report_xfce_version                     # Report the XFCE version (if installed locally).
+    :run_make_then_make_install              # This will first run "make" and then "make install". It is mostly a convenience method, with support for colours.
+    :scookie                                 # Show a lot of information about a specific program.
+    :search_for_tags                         # Search for all programs that have a specific tag.
+    :show_all_about                          # Show all about a specific program, e. g. "htop".
+    :show_compile_chain                      # Show the compile chain for the given program.
+    :show_configuration_options              # Show the configuration options of a specific program, if it has any.
+    :show_versions_of_these_programs         # Show versions of the given programs.
+    :simple_appdir_configure                 # Compile a program via an app-dir prefix, e. g. /Programs/Htop/1.2.3/.
+    :store_abbreviations                     # This will store all abbreviations to the registered program names.
+    :suggest_cookbook_for                    # Suggest a cookbook for a specific program, such as "htop".
+    :symlink_into_the_usr_bin_hierarchy      # Symlink the given Array into the /usr/bin/ hierarchy.
+    :test_this_alias                         # Test whether the input is an alias to a program, such as "ht" towards "htop".
+    :to_current                              # Create a "Current" symlink.
+    :toolchain                               # This will attempt to build a standalone toolchain for compilation, similar to what LFS does.
+    :trad                                    # Compile a program in the traditional manner, aka prefix /usr/. The symbol :traditional is an "alias" to this entry point.
+    :uchroot_chompile                        # Compile via user-chroot prefix.
+    :url_action                              # Support instructions such as /install/php/6.3.1, in particular for www-related use cases.
+    :update_all_ruby_gems                    # This will update all ruby .gem files that are registered in the RBT project.
+    :update_entry                            # Update a specific program-entry, into the corresponding .yml file.
+    :update_kde_application                  # Update all KDE applications (kde apps).
+    :update_tags                             # This will update all registered tags.
+
+So, when you want to invoke :update_kde_application then you can simply
+do this:
+
+    RBT.action(:update_kde_application)
+
+(Note that <b>RBT.actions()</b> is an alias to RBT.action(). Internally the
+RBT project will default to <b>RBT.action()</b> only, though; <b>RBT.actions()</b>
+exists mostly as a convenience-alias for e. g. working with IRB, if you
+forget the API, e. g. plural or singular - both will work.)
+
+In **February 2022** a **new filter-method** was added that can be applied
+to turn a given input argument into a "registered" program. What this
+is meant to imply is that, say, you pass in the argument **htop.yml**.
+The .yml part is superfluous, so that filter-method would turn **htop.yml**
+into **htop**. This is not the only modification that is done there;
+the more important take-home message is that the end user shall never
+have to wonder about any of this. The rbt project will try to make
+sense of the given input at hand, as much as that is possible.
+
+More actions will be added as time permits. There is a secondary advantage
+when using actions, by the way. **If** an action is specified, such as
+via Symbols, then we can internally change which class and .rb file
+handles that action. So perhaps we have some bugs and fixing these
+takes too long, but we still want the specified action to work - in
+this event we could quickly write a small task that handles the
+specified action, without having to worry about side effects.
+
+Note that the above overview does **not** include all available 
+actions; some are mostly internal actions that have very little
+value for regular users.
+
+The actions may be a bit verbose and not necessarily easy to
+read compared to a method.
+
+Consider the following:
+
+    RBT.action(:install_this_rubygem, 'path_to_the.gem')
+    RBT.action(:install_this_rubygem, '/tmp/thor-1.2.0.gem')
+
+This would install this rubygem, if it exists locally, e. g.
+the <b>thor</b>-gem.
+
+Now compare this to this toplevel method:
+
+    RBT.install_this_rubygem('/tmp/thor-1.2.0.gem')
+
+The second variant is a bit shorter and easier to read, in
+my opinion. So it is the better variant, yes?
+
+Well, it depends. Brevity is useful, but think about the
+benefit you get via RBT.action(): you can simply call
+one unified method (e. g. action()) to do the required
+action. And we can add lots of aliases to this, to 
+make working with it easier. And you don't have to 
+worry about **where** the code resides - you just
+use the action without a need to do any manual require
+call.
+
+I think if you think this through for a while then you may
+realise that RBT.action() is not such a bad idea - it
+provides <b>actionable</b> entry points to the whole
+RBT suite.
+
+Since as of <b>September 2022</b> all executables that
+are part of the RBT suite, under the bin/ subdirectory,
+are "actionable". That is they are implemented via
+<b>RBT.action()</b> calls. New executables will conform
+to this new default. The only two exceptions are bin/rbt
+and bin/rbt_config - these two will not use RBT.action().
+But who knows - perhaps at some point in time in the
+future they may.
+
+## Permanently disabling trying to rename the KDE konsole tab
+
+You can permanently disable the renaming of the KDE konsole
+tab via:
+
+    ry --permanently-do-not-rename-tab
+
+## class RBT::KernelConfigSanitizer
+
+class RBT::KernelConfigSanitizer, written in February 2024,
+can help ensure a certain linux kernel config (for the
+.config file that is typically found at /usr/src/linux/).
+
+It reads a dataset from a .yml file, which is also distributed
+via the RBT project. That .yml file is adjusted to my use
+cases, so you may have to keep a separate .yml file adjusted
+to your use cases.
+
+At any rate, class RBT::KernelConfigSanitizer will read
+in the content from that .yml file and ensure that the
+.config file has the specified entries. In other words:
+we can ensure that the linux kernel that is to be compiled
+by you, also has these values. Note that this will only work
+if class RBT::KernelConfigSanitizer can find the corresponding
+key in the given line (for the whole dataset stored in
+.config). In other words: if the configuration option is
+NOT part of any line, then it will not be modified at all.
+This is done so that we can avoid using potentially deprecating
+configuration values, even IF they were specified in the
+.yml file. 
 
 ## Pseudo Macros in use