rbt 0.11.118 → 0.13.27

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
@@ -6549,40 +6611,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
@@ -10089,6 +10117,78 @@ 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.
 
 ## Pseudo Macros in use
 

data/doc/deprecations/deprecations.md

@@ -0,0 +1,3 @@
+08.06.2023:
+
+class RBT::Compile was removed. Use class RBT::Installer instead.

data/doc/removed_source_archives/removed_source_archives.md

@@ -0,0 +1,12 @@
+This file will keep track of which source archives were removed
+past May 2023. I added this file because I wanted to know whether
+there may be replacements for a deprecated archive or whether it
+has been completely removed. So this file may shall note down
+whether there are any replacements.
+
+- libgnomecanvas # removed on 10.06.2023
+- libgailgnome   # removed on 10.06.2023
+- libgii         # removed on 10.06.2023
+- gpdf           # removed on 10.06.2023
+- vinagre        # removed on 10.06.2023; this project was abandoned in 2016.
+- gtkspell       # removed on 14.05.2023; this project was abandoned in 2009.