Installing apps not available in apt

1

This is a general question for advice or what people use… I am more acquainted with Arch, which has extensive packages available, but some of the ones I use daily, like helix, zellij, lf aren’t directly available.

I know I could install them all manually (via cargo, etc) but wondered if anyone has used brew (for Linux) or Nix and would recommend them, or has other recommendations for installing packages? Ideally I like to manage applications the same way…

Nix is tempting, as supposedly it just needs a configuration and can be installed again and again on different set-ups, and always should be the same, but I’ve not quite got my head around its configuration… (it also eats up disk space, I think). Also, both Nix and brew can install apps in the user’s home folder.

2
  • Brew: not available on arm.
  • pkgx: useful for cli/tui programs only, not gui apps altough has some X11 binaries. Adds some latency when starting programs.
  • Nix: best choice in my opinion. Has probably everything you may need, including gui apps.
  • Pipx/(astral)uvx/cargo install/etc: simple solution when your tool is a python or a cargo one.
  • Conda/mamba/micromamba: lots of software available also.

I have used a combination of all these, written wrappers, etc and I’ve ended using nix, it has all the software I may need not in apt, without exception.

1 Like
3

I would search whether those developers provide .deb package or custom repository first.

Nix shouldn’t be too hard, I use it on gentoo and here is the basic set up:

  1. systemctl enable nix-daemon && systemctl start nix-daemon

  2. nix-channel --add https://nixos.org/channels/nixpkgs-unstable

  3. nix-channel --update

1 Like
4

I would recommend against using .deb packages provided by the application developers. Packages are usually built against certain versions of shared libraries. Unless the developer built their .deb against exactly the versions on your OS (unlikely if you are using Debian unstable), you can expect trouble. I have also made very bad experiences with third party .deb packages. Creating a package is more than just extracting the right files into the right locations. You need to consider upgrades between versions of your software as well as upgrades of your OS as well. And also remember that maintainer scripts of .deb packages are run as the superuser and can do anything. It is unfortunately quite common that maintainer scripts of popular .deb software packages simply drop a apt sources.list into your /etc/apt config and install a cron-job that regularly upgrades the package… not nice at all…

If the software you are missing is mainly rust software that can be installed via cargo, you can also consider contacting the extremely active Debian rust team. They are packaging and maintaining massive amounts of software. It is truly outstanding what the team is able to pull. Chances are, they already have the things you are interested in in their pipeline. That being said, these might be of interest to you:

If you want to see this software in Debian, you can find other people with whom you can get it into Debian together via above two links.

1 Like
5

Sadly sometimes it’s the only reasonable option. I’m for example running a .deb of RStudio on my Pocket Reform and Desktop PC because the only alternative it building from source and I really don’t see that happening on the Pocket with the slow CPU it has right now.

6

Right, getting software packaged can be an enormous amount of work (see below). I had a look at the .deb that posit provides. They provide the same deb for Ubuntu 20 and Debian 11 as well as for Ubuntu 22 and Debian 12 which already makes me worried… But they can pull this off by dropping a bunch of shared libraries which otherwise would be provided by the system itself into /usr/lib/rstudio/ and are thus probably relatively independent. Most things get put into /usr/lib/rstudio/ and the few things that do not should not conflict with any other package that is currently in Debian/Ubuntu. The postinst and postrm maintainer scripts also look harmless. It looks okay.

rstudio-desktop seems to be a crazy effort to package (requiring not only R but also java and nodejs…). And there are a bunch of embedded code copies which need to be individually packaged first. People have been attempting to pull this off since 2011. You can see the history in #617296 - RFP: rstudio -- IDE for GNU R - Debian Bug report logs There is even a packaging git repository but the last activity in it was 2 years ago: Debian R Packages Maintainers / rstudio · GitLab

2 Likes
7

Yup, all those are reasons why I’d like to rely on RStudio less but due to my work, I sometimes have to use it. For personal R use I have better alternatives (Jupyter, Shiny)

1 Like