Best practices for using unpackaged software

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.

What’s the best way to go in practice?

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

This is under assumption that You don’t need it for other users of that machine (i.e. it’s your personal workstation).


configure --prefix=$HOME …(--otheroptions=…)

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.

Packaging Tutorial: GNU Hello :: Fedora Docs should be enough to get started.

RPM Packaging Guide is much longer, but not Fedora-specific and use a more traditional workflow with low-level tools.

  1. Fedora neovim package even includes a spec file template, so you can do nvim foo.spec (where foo.spec doesn’t exist) and it starts editing a new file with the template. ↩︎

1 Like

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.

1 Like