What are the best approaches/practices for dealing with unpackaged software that I want to use? By unpackaged, I mean no RPM is available, e.g., Fedora repos, Copr, or RPMFusion or some other trustworthy source. (I am in particular interested in using FriCAS, which unfortunately has this situation.)
From my understanding, generally one downloads the dev packages of the necessary dependencies and then tries to compile according to the readme file and hopes for the best. The drawbacks are that versions of dependencies sometimes donāt agree, and you end up loading your system up with a bunch of build dependencies that are are hard to neatly āclean upā later. The software itself must also be manually uninstalled/updated/managed.
Some options I have gathered from reading around the internet:
Using the nix package manager if the package is available there. Unfortunately I am not familiar with the nix language (but maybe itās worth the investment). Also, I am not sure if there is the potential for conflicts/problems with the host system going with this option.
Building inside some sort of container, but there seem to be many options (toolbx, distrobox, podman, etc.), and I donāt know which tool is most appropriate.
Trying to package an RPM and/or use Copr, but the docs seem daunting.
Somehow āconvertingā the Debian package, though Iām not sure if there is a reliable way to do this.
The best approach is what works for your use case.
Is it worth the effort to manually compile the software, including the potential dependency problems? Remember that any file installed by a system package then replaced by the self-compiled software is a candidate for things breaking regularly during updates (or even immediately if it impacts already installed software).
If there is a .deb package it MAY be possible to use the āalienā package and convert it to an rpm, but there is a likely problem with dependencies there as well.
Learning how to build the rpm package and doing so for yourself seems best, though not necessarily easiest.
Safest bet is to install it in your $HOME (see and check if $PATH contains $HOME/.local/bin and $HOME/bin; which, I think, is set by default). Check configure --help if it offers something like this:
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
This is under assumption that You donāt need it for other users of that machine (i.e. itās your personal workstation).
Before answering the question, it seems like thereās a Docker image for FriCAS, which might be the easier way to run it on a supported platform without building it yourself.
If itās a very simple program with minimal/no dependencies, and I donāt expect to update it, Iāll just use the given build system to install to /usr/local.
Anything more complicated than that, I prefer to write a spec file for an RPM package, because:
You have to figure out the build steps anyway, and write them down so they can be reused (to rebuild/update the software). You could write your own build scripts in any another language, but youāll end up rewriting a lot of common logic provided by RPM macros, handling dependencies manually, etc.
The resulting rpm can be installed/uninstalled/upgraded easily. If packaged correctly, you donāt leave any stray files behind. No worrying that you forgot something in make uninstall. Or that a file changed locations between versions, you built and installed the old version, then built and installed the new version, and forgot about the old file.
There is a wealth of existing tools to work with spec files/RPMs[1]. You donāt need to learn the lower-level tools like rpmbuild nowadays; you could use higher-level tools like fedpkg wrapper for most things.
You can share the spec file or provide the package to others (e.g. via Copr or openSUSEās OBS).
I previously used podman/toolbox containers to build some software, but it ends up being more work maintaining custom build scripts / containerfiles. If you want to build your RPMs in an isolated environment (which I always recommend, so you donāt have unnecessary build deps on your real system), you can:
use mock to build in a chroot,
or the convenient fedpkg mockbuild wrapper (I mostly use this for local builds),
or build on Coprāafter some simple setup, itās literally 1 command copr-cli build <project> <spec/srpm>
Obviously this is a very Fedora/RPM-distro centric view, and not everyone will like writing spec files. But itās relatively simple and works well.
I use a package of batch processing command-line tools (from NASA) that has its own build system. It uses a number of libraries like HDF4+5 and NetCDF that have many compile-time options. Most linux distros donāt enable the required options , so the package does customized builds of libraries. Everything is installed to <package_root>/<standard_directory_tree>. To use it you source a shell script that sets PATH and various default runtime configuration options. Users do sometimes get into trouble trying to wrap the tools in Matlab, R, Python, etc. scripts.
Some linux distro packages canāt use files created by the NASA software, due to a bug or choice of libraries, so I have to build a local version in /usr/local/src. I use the stow package to create symbolic links in the /usr/local/ tree so it is easy to remove the customized package when the distro package gets fixed.
Thanks all for the useful answers. The RPM option worked out just fine and didnāt take too much effort to figure out after going through the packaging tutorial linked by @jn64. It also seems like mock and fedpkg make it easy to have an isolated build environment, which I did not know about before.