You can also use a String as input to the method rather than a Symbol:

The Software Manager project Introduction to the "Ruby Software Manager" Project (RSM), formerly called "Ruby Build Tools" (RBT)

Welcome to the Ruby Software Manager project, also called the RSM suite - getting work done! Making compiling and installing software great again. \o/

This documentation here attempts to detail the various objectives for the RSM project, including its history, as well as how people may benefit from the project.

Let's now jump right into the main goals of this project - the primary objectives.

The primary objective of the RSM project The primary objective for the RSM project is to support and help users whenever the need arises to install software, on a given computer system. For instance, if the user wishes to install or compile a specific program.

The RSM project should remain flexible for such a use case. For example, say that there is a source archive available at the following remote URL:

https://github.com/htop-dev/htop/releases/download/3.3.0/htop-3.3.0.tar.xz

We would like to support the following commandline invocation, in order to compile this source archive (a .tar.xz tarball) from source:

rsm https://github.com/htop-dev/htop/releases/download/3.3.0/htop-3.3.0.tar.xz

The RSM suite will do various steps to achieve this. Specifically it will do at the least the following steps:

(1) download the remote archive locally (2) extract the tarball (3) prepare the archive for compilation (4) try to compile the program at hand (5) report all findings that are relevant to the user [SUCSESS / FAILURE]

In the ideal outcome, this remote tarball has been downloaded and then compiled successfully (aka installed successfull).

This is not the only use case, of course.

If the remote URL is a binary package, then RSM should install it. If it is a local archive, then this should be installed as well.

This basically sums up the primary objective of the RSM suite. Let's next have a look at secondary objectives for this project.

The secondary objectives of the RSM project The RSM project should help in regards to users wishing to maintain the software on their computer system in general. RSM thus needs to be able to act as a layer that can be helpful to the user, no matter the underlying operating system.

Various additional scripts are available that aid in various situations. For instance, one script can modify the PREFIX used in a Makefile. This allows the user to quickly use any other prefix variable, irrespective over as to whether that Makefile supports it or not.

Support for different operating systems by the RSM project The primary operating system for the RSM suite is Linux, that is the Linux operating systems (henceforthwith simply called Linux in this document.

Linux is, in this regard, a first-class citizen. Everything pertaining to the RSM project will be tested and developed first and foremost on Linux.

However had, other operating systems than Linux should also be supported. Whenever ruby works on a given operating system, the RSM suite will attempt to support that operating system. This may require some changes every now and then, though, as different operating systems have different features. For instance, HaikuOS favours a filesystem that is not easily supported by Ruby.

Additionally, when we refer to allowing a user to install software, this typically refers to taking the source code and compiling this source code - in other words: to simply compile the program at hand, from a remote URL.

While the primary platform for the RSM project is predominantly the Linux platform, whenever possible support for other platforms will be added as well. In fact, it is a secondary goal for the RSM project to support all 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 RSM will eventually try to support as many different operating systems as possible, provided that ruby can run on such a system.

As mentioned already, Linux is the main target OS for the RSM project, so things will always be tested on Linux first. Most development for the SoftwareManager-project does indeed take place on a Linux system currently.

Ideally, in the future, we could reach a state where we can test the SoftwareManager 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. Windows is the second operating system that SoftwareManager will support, by the way; it is less well-tested than the Linux-specific code of the SoftwareManager-project.

The History of the SoftwareManager Project (RSM). Back in the days - and I still am of this opinion even today - I thought that shell scripts ultimately tend to grow in complexity way faster and steeper than equivalent code writte in other, better programming languages.

They also lean towards becoming really ugly, which makes it hard to further extend them with more code, at which point sooner or later maintaining them becomes a burden.

When maintaining code becomes hard to maintain, you often start to lose interest and eventually cease maintaining it or adding anything new to it. This was the case the with Linux distribution called GNU Sorcery - all their recipes were written in shell scripts.

Back in 2004 or so, I was using GoboLinux, and while the shell scripts used in GoboLinux were fairly elegant, I did not understand them at all. So I decided to re-create the logic found in those shell scripts, but primarily in ruby, storing the instructions in .yml (YAML) files.

Specifying another source location Normally all source archives are stored into /home/x/src/ - or, rather, the variable the user set in the configuration file. (On my home system this is the directory I use for keeping all source-archives.)

But is this always the case, that a user keeps all source archives within a single directory? Of course not. Sometimes the user may want to use another source location. Precisely due to this reason, a commandline flag exists, to allow specifying the target path to another directory that is to be used as source archive. That commandline-flag is called --use-this-source-location=.

An example for using this follows, in order to make use of the path /depot/j/gcc-12.3.0.tar.xz.

ry gcc ntrad --use-this-source-location=/depot/j/gcc-12.3.0.tar.xz

Specifying another programs directory On my home setup, the programs-directory I use is /home/Programs/.

GoboLinux uses the directory /Programs/ as the programs-directory.

Some users may want to use another directory, such as /opt/. We thus need flexibility here.

The user needs a way to designate a different programs directory. This is done via the commandline-flag --use-this-programs-dir=.

Invocation examples:

ry htop --ntrad --use-this-program-dir=/opt ry htop --ntrad --use-this-programs-dir=/opt

This will become the programs directory for the current compilation run. So, if compilation succeeds, the user may then have the AppDir at /opt/Htop/3.3.0/.

Obtaining the number of registered programs The number of registered programs in the SoftwareManager-project can be obtained via the commandline, by issuing any of the following commandline instructions:

ry --registered_programs? ry --n_programs? ry registered_programs?

The number of registered programs can be queried via the commandline as well, like in this way:

ry --n_programs?

Although the output may be a little bit different.

This would then output something such as this:

→ 3330 programs registered as of 30.01.2018. → 3414 programs registered as of 18.09.2018. → 3635 programs registered as of 01.12.2019. → 3656 programs registered as of 12.01.2020. → 3846 programs registered as of 28.02.2025.

(The format may be a bit different to the above, but the information content is the same.)

Static Compilation It is possible to compile an application statically, by passing static to the main class SoftwareManager (software_manager.rb).

Specific example:

ry make static --ntrad

Note that this will not work for every program.

In the event that you, on the commandline, try to enable static compilation, and the yaml file specifies otherwise, such as via a configure switch like --disable-static, we will ignore the latter option and allow the user to specifically overrule this setting. The SoftwareManager-project always assumes that the user knows what he or she is doing.

Note that you can also zero these flags via a commandlie option:

ry strace --no-compile-time-flags ry strace --plain

This option means that all CFLAGS etc... will be ignored altogether; that is, they will set to an empty again.

Using a different set of configure-options Sometimes you may want to overrule, on the commandline, the configure options that are to be used by a program.

You can do so via the switch --use-these-configure-options=.

Usage example:

--use-these-configure-options="--enable-shared --enable-bootstrap --enable-languages=c,c++,lto,objc,fortran --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-compatible --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --disable-install-libiberty --with-gnu-ld --verbose --with-arch-directory=amd64 --disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux"

Complete usage example:

ry gcc --use-these-configure-options="--enable-shared --enable-bootstrap --enable-languages=c,c++,lto,objc,fortran --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-compatible --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --disable-install-libiberty --with-gnu-ld --verbose --with-arch-directory=amd64 --disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux"

ry poppler --use-these-configure-options="--enable-xpdf-headers"

Disabling the use of cookbook aliases The cookbooks submodule, part of the SoftwareManager-project, makes use of several aliases to program names. This is mostly a convenience feature.

Sometimes this may lead to unexpected or unwanted results, such as when you want to compile program a, but the cookbooks-submodule automatically attempts to renames the program to b instead.

In order to avoid situations similar to this, a commandline-option exists for the main SoftwareManager class.

Invoke it like so:

ry sdlttf --do-not-use-cookbook-aliases ry sdlttf --do-not-use-cookbook-alias

This will specifically disable making use of cookbook-aliases for the current compilation run.

Compiling via the --rootprefix option Using the --rootprefix is exactly identical to passing the following flag:

--prefix=/

Nothing more than that.

The option was added in November 2021 because I needed to compile all coreutils binaries into the /bin/ subdirectory on my home setup, and I needed these to be compiled statically, to avoid any problems during reboot when some shared libraries can not be found.

The exact command I used was:

ry coreutils --static --rootprefix

Installing/Compiling the various xcb components If you, like me, get tired of installing the various xorg-related xcb components then the following command should be of help here:

ry --compile-xcb-components

This will install the xcb-components in the correct order (actually it will compile the xcb-components).

Aliases exist for this:

ry --compile-the-xcb-components ry --compile-all-the-xcb ry --compile-xcb

Program Versions You can overrule the version specified in the cookbook yaml file from the commandline. To do this, look at the following two examples:

ry nano --version=2.1.9 ry nano --version=2.2.2 ry nano --version=2.4.3 ry gtk+ --version=2.24.29

Do note that this has a chance to fail right now, i.e. if the remote mirror does not have this specific version, or if you do not have this program available locally.

You can also use a slight shortcut:

ry nano --v=2.4.3

And an even shorter variant is to just give the leading name, and have the SoftwareManager script just pick one that fits:

ry python --2

You can also use a more complete copy-paste version setting (like you copy, then paste the full name), like this:

ry nano --version=pango-1.24.2.tar.bz2

Searching for something To search for something, do this:

ry ruby search

To find a specific list of packages, do this:

ry pyt*

The * will tell us that we intend to find all packages starting with "pyt".

This can work with single letters too, that is - if you wish to discover all programs that are registered in the Cookbooks project starting with a, you can do:

ry e*

The "*" is the important token here that will trigger this functionality.

Be careful though if you use a shell like Bash or Zsh - the * can be expanded by the shell.

Prefix Tag You can specify a different prefix to use when compiling a program.

To do this, do:

ry gimp --prefix=$J ry gimp --prefix=/opt

Some nifty shortcuts exist. For example, to compile gimp into a standalone directory, into /Programs/Gimp/LatestVersion, you can do:

ry gimp ntrad ry gimp non_traditional

Please also note that you can use the Option noprefix to avoid using any specific prefix. (This is the same as passing --prefix=/usr/local though on GNU systems.)

Do note that you can also use "compound-prefixes". These are prefixes such as /Programs/Xfce/4.12, where you may want to put all xfce-related programs into.

Syntax for this functionality goes like this:

ry xfce4panel --prefix=:xfce

In order for this to work, an environment variable called XFCE_PREFIX may have to exist. If such an environment variable does not exist, then the program_version is guessed. I recommned to set such a prefix variant.

The leading : is important here - do not forget it.

Copy the whole yaml database. You can copy the whole yaml database by issuing:

ry x copy_yaml

Gobolinux Recipes In order to create Gobolinux Recipes for i.e. python, do this:

ry python goborecipe ry python --goborecipe

Take note that this will create the recipe in the current working directory.

class SoftwareManager::Action::Cookbooks::MultiUrlDisplayer class SoftwareManager::Action::Cookbooks::MultiUrlDisplayer can be used to quickly show several programs and their associated remote URLs to their respective source archive on the commandline.

In order for this to work, naturally, these have to be part of a component, and registered in the cookbooks.

Since as of April 2024 this class is now part of the Actionsubmodule, and thus an actionable component of the SoftwareManager suite.

Let's look at a specific usage example to demonstrate this functionality:

action(:MultiUrlDisplayer, ARGV) action(:MultiUrlDisplayer, 'kde-plasma5') action(:MultiUrlDisplayer, 'plasma5') action(:MultiUrlDisplayer, 'audio_suite') SoftwareManager.action(:MultiUrlDisplayer, :audio_suite)

Or from the commandline, via multi_url_displayer:

multi_url_displayer plasma5

The output will show all remote URLs of, for example, the KDE5 plasma components.

Example listing:

plasmabrowserintegration: https://download.kde.org/stable/plasma/5.19.4/plasma-browser-integration-5.19.4.tar.xz plasmanano: https://download.kde.org/stable/plasma/5.19.4/plasma-nano-5.19.4.tar.xz plasmaphonecomponents: https://download.kde.org/stable/plasma/5.19.4/plasma-phone-components-5.19.4.tar.xz kwaylandserver: https://download.kde.org/stable/plasma/5.19.4/kwayland-server-5.19.4.tar.xz

On my computer system the output this will generate is as follows (as an image):

If you are only interested in the raw URL entries, on the right side, without the leading name, such as when you wish to use wget to batch-download this easily, try any of the following variants from the commandline:

multi_url_displayer plasma5 --show-only-URLs multi_url_displayer plasma5 --only-URLs multi_url_displayer plasma5 --show-only-urls multi_url_displayer plasma5 --raw

The entry status_of_the_project in a cookbooks .yml file In June 2023 the entry status_of_the_project 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 actively maintained, so this entry is primarily useful when a project was abandoned.

Installing older versions of programs What if the user wishes to install an older version of, say, python?

The corresponding cookbook.yml file normally "supports" only the version that is specified in archive_name:.

For example, if you jump to the "python:" entry in the cookbook.yml file, you will see that its version is 2.5.1 or something like that.

This can be changed permanently by writing another name/version there, into that file called python.yml.

Because editing of various cookbook.yml files can be a little annoying, and because flexibility is nice to have, there exists another way to specify a different version manually on the commandline:

compile python --version=2.4.1

This works with every version, even "newer" ones.

The name of the version should however be part of the filename.

For more information about this, and an even easier way, jump here to.

Global flags Global flags are compile-time flags that you can use, which will be appended to GNU configure runs.

These flags are stored in the file global_flags.yml

You can either manually modify this file, or use commandline instructions to modify this file.

For example, if you wish to append --disable-static to all configure invocations via RBT, then you can issue the following command:

ry --add-global-flag=--disable-static ry --add-global-flag --disable-static

Likewise, to remove a global flag, you can do:

ry --remove-global-flag=--disable-static ry --remove-global-flag --disable-static

You can reset all global flags again, by issuing:

ry --clear-global-flags

Note that since as of March 2025, global-flags are slightly deprecated; they never were too terribly useful to begin with, from the point of view of the SoftwareManager project.

Optional dependencies for the SoftwareManager-project The wget gem is recommended as an optional dependency for the SoftwareManager gem, but you can also use the SoftwareManager project without the wget gem just fine. In that case, if the wget gem is not available, the SoftwareManager project will attempt to use the wget binary via a system()-call, hence an "external" program, to ruby.

This requires the installation of wget e. g. from this URL (or from your package manager's repository), unless wget is already available on your local computer system:

http://ftp.gnu.org/pub/gnu/wget/?C=M;O=D Of course, most Linux systems will have "wget" available by default, so the above more applies towards operating systems such as windows (although more recent windows versions also include a linux-subsystem including bash, the WSL, so this should also not be a problem).

How does the format of a cookbook recipe, the respective .yml file, look like? Each cookbook entry is just an individual yaml file, with the extension name being .yml.

For instance, information about the programming language ruby will be stored in the file called ruby.yml; information about the programming language python will be stored in the file python.yml; information about the mate-desktop will be stored in the file matedesktop.yml.

If there are any "-" tokens as part of the name, then these will be removed when RSM tries to determine the filename.

This yaml file should contain all the required information to get that particular program to install on a given system.

Additional information can be added as well, such as maintainer(s), extra information of the program at hand, tips and hints in how to install or use the program, sed-modifications, pkgconfig files (aka .pc files) that are installed alongside with, patchsets that are to be applied, binaries, headers and libraries and so on and so forth.

It can be a quite detailed file, mostly due to being able to allow some flexibility during installation.

Many programs "out in the wild" are well-behaving and will honour a --prefix variable given (or -DCMAKE_INSTALL_PREFIX=, such as in use by programs that depend on cmake, for compilation). Such programs usually require little to no modification.

Unfortunately, some other programs come with flawed installation scripts, hardcoded paths or workarounds that have to be employed to get these to work - very often sed-operations, such as done in the LFS project. Some programs may also have already become obsoleted, due to changes e. g. in glibc/gcc and other programs. If there is no maintainer of the downstream package then this normally means that other people have to either maintain that package; or provide patches to get this projects to work again.

As a reference project, the LFS project provides a lot of useful information in how to get many programs to work. I consider the LFS project to be hugely important for the whole Linux ecosystem, much more important than the various different distributions.

At any rate, let's now have a look at the fish.yml recipe, to give a specific example and explain that.

This fish.yml file will look like this, as of February 2025:

fish: binaries:

fish
fish_indent
fish_key_reader short_description: | FISH is an interactive (commandline) shell. description: | FISH is the Friendly Interactive Shell, a smart and user-friendly command line shell for macOS, Linux, and the rest of the family. url1: https://github.com/fish-shell/fish-shell/releases/download/2.7.1/fish-2.7.1.tar.gz url2: http://fishshell.com/files/2.1.0 url3: http://sourceforge.net/projects/fish/ homepage: http://fishshell.com/ tags:
shell prefix: f keep_extracted: yes last_update: 10.02.2025

The very first entry, on top, is the name of the program itself, in this case, fish.

While this part could in theory be omitted (since the name of the program is already stored as the first part of the very filename), I found that it is useful to have this entry within the file, primarily as a visual identifier if you work with it in an editor. It helps me a lot, for instance.

Note that no - or _ characters are allowed there in this entry - it is really a stripped down name of the program at hand only.

If the name would be e. g. 'gtk-doc', with an URL such as http://ftp.gnome.org/pub/gnome/sources/gtk-doc/1.26/gtk-doc-1.26.tar.xz, then the name there for the gtkdoc.yml file would have to be gtkdoc: - thus, all '-' were removed. The name that appears there is also the name of the .yml file at hand. The .yml files may also not include any '-' or '' characters. Do also note that while I am following this convention since many years, it may one day be changed to allow for '-' and ''. But for the time being, the strict requirement is that we may not have '-' or '_' characters there.

Next, let's look at the entry binaries:. This entry tells us which binaries/executables this particular program will install. This also allows us to remove binaries in the /usr/bin/ hierarchy, if you compiled into an AppDir prefix - for more information here, see class SoftwareManager::PurgeBinariesOfThisProgram.

The next entry is short_description, which is e. g. equivalent to slackware's pkg-format, as introduction to the specific program at hand, in a short notation.

Then we have the entry main description, followed by several url entries. The first url entry, aptly named url1, is the most important entry. It tells us where to find the archive to the program at hand.

This is ideal the URL to an existing archive, but it could also be a github repository, in principle.

Then we also have the homepage entry, which denotes the homepage of the program (or any other webpage that has relevant information, in the event that there no homepage entry exists for that particular program).

Then we have tags: which just groups the program into popular tag-classifiers, such as "shell" in this case. Then the prefix in use, which is f for false, meaning "non-traditional" aka "appdir" prefix such as GoboLinux makes use of. Then there is the keep_extracted setting, which tells us whether to keep the archive extracted or not after extracting/compiling it. Last but not least, the last_update tag tells us when this program was last updated. The default format here is dd.mm.yyy, but shortcuts are allowed. For example, Oct, for October, can be used rather than 10, and so on.

The next entry is prefix. This one is mostly synonymous for the --prefix= option given to GNU autoconfigure based projects.

A prefix value of t means true, which stands for /usr/. A prefix value of f means false, which stands for the particular AppDir-like prefix. In the case here, for fish, this would expand to /Programs/Fish/2.7.1. GoboLinux uses a very similar AppDir layout by default, although with slightly different program names that can also be upcased, e. g. "KDE-Libs" and so forth. (the RSM project will offer both variants here; the GoboLinux naming scheme, and the simpler scheme where only the first character is upcased, and the other characters are all downcased.)

There are many more entries, most of which should be documented under the doc/ subdirectory of this gem. What follows next are some more mentions of important (and less important) entries.

The entry configure_base_dir: unix determines which base directory is to be used. In the above example, RBT would cd into the directory called unix/. This is important for some programs such as tk or xvid - have a look at their directory structure to understand this setting.

Since as of December 2018 it is possible to use github URL that are truncated. Take the program conky as an example. It has an url like the following:

https://github.com/brndnmtthws/conky/archive/v1.11.0.tar.gz

This will now be automatically expanded into the correct naming scheme, aka conky-1.11.0. No idea why GitHub is not doing so on their own automatically; the tarball is even wrongly built, since it extracts to precisely that name after download. But anyway, ask GitHub about this, not me.

The content of these individual .yml files is essentially just a Hash that describes the various attributes of the given project at hand (and some additional information when it is required for installing/compiling this program).

Note that since as of January 2020, you can also just provide a new URL and register a program this way anew.

Commandline Example for this:

ry http://ftp.gnu.org/pub/gnu/kawa/kawa-3.1.tar.gz

Packaging the SoftwareManager scripts You can package all the latest SoftwareManager scripts by using a commandline flag such as this:

ry package_cookbooks ry --package_cookbooks

This will create a directory in /depot/archives/ and package the SoftwareManager 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 on windows and may quickly and conveniently need to transfer the files, for whatever the reason(s).

Remove Program To remove a program, you can use:

remove_this_program

On GoboLinux this would be done via RemoveProgram.

Porg You can use the program called porg to install a program.

Porg will keep track of program files that are installed.

You can also disable porg from the commandline via:

ry --disable-porg ry --disable_porg ry --disableporg

Or just directly edit the respective .yml file.

Available programs versions

If you only need to know the URL to the BLFS homepage, to embed it for display into a webpage perhaps or to merely display it onto the commandline, you can use the following simple toplevel-API for this:

SoftwareManager.blfs(:name_of_the_program_goes_in_here) SoftwareManager.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:

SoftwareManager.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 SoftwareManager::LFS to build/create a LFS from scratch. This is presently (as of the year 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:

ry 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 it can be used in the following way via the commandline:

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 the SoftwareManager project).

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 SoftwareManager project.

For the time being, though, only pasting is supported - there is no plan to bundle the information into the SoftwareManager project at this point in time.

Usage example for this functionality follows:

ry --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 the user 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 for this:

ry kerberos --use-blfs-instructions # Compile kerberos in the BLFS way.

Since LFS/BLFS is such a useful project, the SoftwareManager suite has some more support in this regard. This is rather unsurprising, as the Linux From Scratch (LFS) Project has instructions on how to compile programs from source. So it has a somehwat similar meta-goal, like the SoftwareManager project.

These instructions are immensely useful. A lot of the information from LFS/BLFS was integrated into the SoftwareManager 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 curl.

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:

ry gcc --paste-blfs-page

If you want to show all programs that have a blfs entry, use the following command:

ry --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:

SoftwareManager.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 in the RSM project, use this toplevel method:

SoftwareManager.n_BLFS_entries? # => 776 - as of March 2025

Minimal chroot environment and improved chroot environments On my home system I tend to have a working backup system at /depot/chroot/.

In this directory I tend to have all important programs "duplicated", so that I can safely re-compile when necessary.

Which compile-chain may be used to build up a minimal chroot?

I will try to list the options here, as I use this on my system (or a new system):

ry make --static --chroot ry bash --static --chroot # <- This may already suffice. ry mpfr --chroot ry gmp --chroot ry mpc --chroot ry sed --static --chroot ry grep --static --chroot ry coreutils --static --chroot ry ruby --dontuseconfigureoptions --chroot ry python --chroot ry gawk --chroot --static ry nano --static --chroot

Generate my custom rc-files next:

rcfiles --populate-this-dir=/depot/chroot/AUTOGENERATED/ rcfiles rcfiles --populate-this-dir=/AUTOGENERATED/ ry gcc --chroot --dont-symlink ry ncurses --dontuseconfigureoptions --chroot ry zlib --chroot ry nano --chroot ry bison --static --chroot ry m4 --chroot ry curl --chroot ry isl --chroot ry flex --chroot ry nasm --chroot ry gc --chroot ry tar --chroot ry texinfo --chroot ry openssl --chroot ry libelf --chroot ry elfutils --chroot ry ccache --chroot ry lzma --chroot ry cmake --chroot ry file --chroot ry pkgconfig --chroot ry gperf --chroot ry popt --chroot ry git --chroot ry pcre1 --chroot ry pcre2 --chroot ry libunistring --chroot ry gettext --chroot ry check --chroot ry libxml2 --chroot ry mtools --chroot ry gzip --chroot ry doxygen --chroot ry strace --chroot ry valgrind --chroot ry graphite2 --chroot ry tcl --chroot ry expect --chroot ry dejagnu --chroot ry patch --chroot ry libogg --chroot ry sqlite --chroot ry libpciaccess --chroot ry libdrm --chroot ry pixman --chroot ry llvm --chroot ry enchant --chroot

Compiling glibc should come last here:

ry glibc --chroot --do-not-symlink --do-not-run-ldconfig

Do not forget to also copy a statically compiled version of busybox.

Also, if the chroot-command fails, make sure that you have copied the ld-linux shared objects, such as:

'/lib64/ld-linux.so.2' -> './ld-linux.so.2' '/lib64/ld-linux-x86-64.so.2' -> './ld-linux-x86-64.so.2'

In March 2025 it was realised that the above steps are a bit brittle, so it made sense to think of an alternative approach: by making use of SoftwareManager to enable the individual early steps used by LFS. These early steps will properly set up a chrooted environment, which is then used to compile the rest of a Linux system. Thus, SoftwareManager will be adjusted to allow for these individual steps as well.

Auto-resolve compile-related problems via the SoftwareManager project Since as of September 2017, the SoftwareManager scripts can also give some advice how to resolve some compile-related problems.

This is currently fairly minimal, but it will be extended subsequently in the future. It was also a reason why the namespace Libtool has been integrated into SoftwareManager, as SoftwareManager::Libtool. This allows us to auto-correct some libtool-related problems and keep all libtool-related code within that namespace.

Module programs: making use of the extended cookbook dataset Module programs refers to the ability to access all registered programs that are reigstered in the SoftwareManager project, at the toplevel "SoftwareManager." namespace. In other words, we can "copy" the program names onto the SoftwareManager top-level module "namespace".

For instance, htop would be available at

SoftwareManager.htop

if it is called as a "module program".

Take note that this is NOT the default behaviour. By default, the above way to call the method .htop() on SoftwareManager would not work.

As another example: the program binutils would, as a module program, be available at:

SoftwareManager.binutils

And so on, and so forth. No "-" characters are allowed there, as these are not allowed in methods written in ruby.

Note that this will return a sanitized Hash that holds all the information required to compile the given program from source - this dataset thus describes these programs. That information may still have to be interpreted by a program, of course.

Simply require the necessary file for this:

require 'software_manager/module_programs'

After that, the above methods will work. Let's see a few more examples for this:

SoftwareManager.wayland SoftwareManager.ruby SoftwareManager.php SoftwareManager.gnomemimedata SoftwareManager.evince

Note that reader methods via '?' character are available too, although this could be toggled. The '?' will access the datastructure as a Hash rather than a specialized object.

Invoke it like so:

SoftwareManager.htop? # => {"archive_size"=>323560, "short_description"=>"ncurses-based interactive process viewer.", "github"=>nil, "set_env_variables"=>{"LDFLAGS"=>"-ltinfow"}, "homepage"=>"http://hisham.hm/htop/", "binaries"=>["htop"], "headers"=>[], "libraries"=>[], "postinstall"=>[], "pre_make_commands"=>[], "required_deps_on"=>["glibc => 2.3.2", "ncurses => 5.6"], "tags"=>[], "pkgconfig_files"=>[], "program_path"=>"/home/x/src/htop/htop-2.0.2.tar.xz", "program_full_name"=>"htop-2.0.2.tar.xz" ... and so forth }

This functionality exists primarily because it may be easier for you to use the above API calls. Internally though, the SoftwareManager project will prefer API calls such as SoftwareManager::Cookbooks::Cookbook.new :htop instead.

Note that the above works without any '-' as part of the name, so there will not be SoftwareManager.gnome-mime-data() - it would be SoftwareManager.gnomemimedata().

When may you want to use this? Well, it could be used if you do want to use a simpler API. It is very easy to remember, too: just use 'SoftwareManager.' followed by the name of the program, without any '-' or '_' characters there.

How to register all programs It may be that you want to register all programs in the yaml database that is supported by the SoftwareManager project.

In order to do so, run this command:

ry --register_all_programs ry --rap

Batch-updating all registered gems in the SoftwareManager project You can batch-update all registered gems via

rsm --update-all-gems

Note that this will only work if the corresponding .gem is part of the Cookbooks submodule of this project.

Updating all registered rubygems It is possible to batch-update all registered rubygems via:

ry --update-all-gems

The boolean constant ALSO_AUTOMATICALLY_INSTALL_THE_UPDATED_GEM, defined in class SoftwareManager::Action::SoftwareManager, controls whether the updated gems will automatically be installed by the SoftwareManager project. If set to true then the SoftwareManager project will not only download the respective gem, but also install it. Since not everyone may want this, the constant handles this case for the time being - I personally like this constant set to true, since it saves me some keystrokes in the long run.

If you do not want to, or can not, update all registered .gem entries, yet you still want to install the .gem files that are registered, then you can use this commandline invocation variant:

ry --install-all-rubygems

This will install all registered .gem files, in an alphabetical manner. Dependencies will not be checked that way, but in principle if all .gem have been properly registered in the Cookbooks submodule, then this batch-gem installation should work just fine.

Modifying the cookbook-dataset via a webpage In the past, already since as of 13.09.2007, it was possible to modify the cookbook-dataset via webpages - usually via a .cgi webpage.

As of March 2025 this is no longer possible, but it may be brought back one day. Stay tuned in this regard.

Patches to the cookbook-dataset and applying those patches automatically Some programs sometimes need a patch, in order for successful compilation.

The entry that is to be used here, in a corresponding .yml file, used to be apply_patch:. Since as of 2025, this is now simply called patch:.

It is to be used like this:

patch:

https://connie.slackware.com/~alien/slackbuilds/id3lib/build/id3lib-3.8.3_gcc4.diff

This feature is not that important, but sometimes a program may need a patch, so the feature had to be added, in order to allow users to automatically download and apply such patches, before compilation begins in earnest.

The functionality of class ProgramInformation ProgramInformation is a fairly small class. The motto behind it is to do one thing well.

The two methods .first and .last, part of class ProgramInformation It is possible to obtain the name of a given program at hand, and the associated version, like so:

require 'software_manager/requires/program_information.rb'

x = SoftwareManager::Actions::ProgramInformation.new('ruby-2.5.0') puts x.first # => ruby puts x.last

Note that other toplevel variants exist as well, such as:

SoftwareManager.return_name() SoftwareManager.return_version()

The idea here is to be as flexible as possible, so that the user cherry-pick whatever is preferred. Personally I usually use the toplevel method variants, as these are shorter to type.

Tests for SoftwareManager::Actions::ProgramInformation class ProgramInformation is very important to automatically determine the program-name and the program-version of a given String.

As this class is very important, it also comes with a test suite. These tests are stored mostly in the file called software_manager/test/testing_program_information.rb, which will test the Array called SoftwareManager::ProgramInformation::ARRAY_TEST_THIS_AS_INPUT.

Not all tests may work perfectly well, but for the most likely input it should work fine. So like 98% of all use cases that a user or developer may ever encounter. It should do well.

module SoftwareManager::Actions::Validations module SoftwareManager::Actions::Validations has been added in January 2025. The main objective of this module is to gather all validations in one place. Validations in this regard means quality-control code - in other words, code that can be used to improve the quality of the whole codebase in the SoftwareManager suite.

Handling errors in the SoftwareManager project Some problems and errors may happen during compilation or installation of programs.

Before this statement is further explained, let's briefly review how to disable checking for errors in the SoftwareManager project automatically. You can use the following commandline flag for disabling error checking:

ry --no-error-checking

This allows the user to bypass error-checking for the current compilation run. Let's have a look at the feature to autocorrect some errors.

In the past, the SoftwareManager suite handled errors mostly via the toplevel area, that is, into the namespace module SoftwareManager, as well as an ad-hoc registry of common errors and problems. These were handled via one, or several, toplevel instance variables.

This approach was changed in 2025. Specifically we now first register all known errors and problems; this step is not yet reasonably complete. Once it has progressed more, the SoftwareManager suite will attempt to handle some of these errors automatically - or at the least give the user an option to decide on his or her own how to handle these errors and problems.

In the past, we registered the problems into the toplevel, and then allowed a toplevel-API such as:

SoftwareManager.error_message?

to show these.

Note that this used to be reset to nil, its default value, whenever a new program is compiled.

In April 2024 this was changed. First, we will finish by detecting all errors and problems. Once that is done, we will add code that will try to fix such problems.

Sometimes it may not be wanted to stop on errors, in particular if the error reported is not a real error. Thus, the user needs to have a way to overrule this behaviour, which can be done by the following commandline flag:

ry --dont-stop-on-errors ry --ignore-errors

The latter commandline flag still works in 2025 by the way; I sometimes have to use it to bypass wrongfully reported errors.

This would instruct SoftwareManager::Action::SoftwareManager to not stop on errors and instead (try to) continue.

Autocorrecting some errors in regards to the SoftwareManager project The various SoftwareManager scripts can attempt to auto-correct some errors. This is currently a feature that is to be tested more thoroughly; it may not work flawlessly yet.

The errors that the SoftwareManager project can auto-correct are mostly related to libtool right now.

If the file use_autofixing.yml contains a String called t or true, meaning "enable autofixing", then auto-correcting will be used.

There is another option that has to be set to true though, which is the "is_on_roebe?" settings, which indicates my home directory use.

Presently (Sep 2017) this option does not work too reliably, so it is still tested. You can test it too though if you enable "is_on_roebe".

In 2025 I decided to adjust the above a little; auto-fixing issues will still be a desired feature, but first we really need to document all existing errors and problems, and handle these. Only then should we begin to extend the auto-fixing part of the SoftwareManager project.

Querying the prefix to be used If you have the need to find out the prefix that will be used, you can issue the following query:

ry htop prefix? ry htop --prefix?

class SoftwareManager::Actions::Gitty class SoftwareManager::Gitty is a helper class. It ultimately wraps over the "--gitty" commandline instruction class SoftwareManager::Action::SoftwareManager uses.

The SoftwareManager::Actions::Gitty class can be used to quickly checkout the git sources of a remote 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 SoftwareManager namespace, if it has a corresponding entry called git_url 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 gitty.

SoftwareManager::Action::SoftwareManager class SoftwareManager::Action::SoftwareManager was added in March 2024. It has replaced the older class called 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 SoftwareManager.action() 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 is complete as of 2025.

class SoftwareManager::Action::SoftwareManager: feedback the URL of various programs at the same time Say that you wish to find out the URL to various programs at the same time.

You can use this the following commandline invocation for this:

ry --url-for-these-programs=php,ruby,python,m4,php

This will show a result such as:

Entries that are included more than once - such as php in the above made-up example - will only be shown once.

class SoftwareManager::Action::SoftwareManager - 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. SoftwareManager::Action::SoftwareManager will proceed to compile the first entry of this directory.

This allows the user to be lazy and efficient. The above instruction will simply compile the very 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:

ry php*.xz ry tar*.xz

I recommend that users of the SoftwareManager suite also use an alias such as "this", but of course this is up to that user, not to me. For me, personally, just typing "this" is very convenient should I need it.

Internals of class SoftwareManager::Action::SoftwareManager class SoftwareManager::Action::SoftwareManager is the main class of the SoftwareManager-project, as it allows the user to compile or install a program from source.

It is, more or less, the central entry point to the SoftwareManager project - even though you can invoke the other .rb files directly, SoftwareManager::Action::SoftwareManager often provides a simpler convenience access means to the disparate functions that constitute the SoftwareManager-project. This class integrates other classes, sort of like a glue.

This subsection here will explain a few key decisions made, in the long run; and will also explain a few internals used by this class.

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 SoftwareManager-project one day.

The method set_configure_base_directory(), 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.

Some commandline options for class SoftwareManager::Action::SoftwareManager explained As was already written down somewhere else in this document, you can pass in several commandline options to class SoftwareManager::Action::SoftwareManager.

You can also use commandline options that include -- 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 weechat.yml, include an option such as --enable-gtk. 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:

ry weechat --disable-gtk

This will now overrule the setting in the weechat.yml file for the given compilation run, and compile weechat with gtk disabled. 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

Name		Name	Last commit message	Last commit date
Latest commit History 4 Commits
LICENSE		LICENSE
README.md		README.md

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

You can also use a String as input to the method rather than a Symbol:

Generate my custom rc-files next:

Compiling glibc should come last here:

About

Releases

Packages

License

rubyFeedback/SoftwareManager

Folders and files

Latest commit

History

Repository files navigation

You can also use a String as input to the method rather than a Symbol:

Generate my custom rc-files next:

Compiling glibc should come last here:

About

Resources

License

Stars

Watchers

Forks

Releases

Packages 0

Packages