I find myself obliged to use Banana Accounting. For Linux, it is distributed as
with the following stated system requirements:
- Ubuntu 18.04 or more recent versions (for other supported distributions we do not provide support)
- 180 MB of disk space
- Internet connection to download the software, activate the subscription, and access the templates and help function of the program
Options for running this software on NixOS seem to include
Obviously, I’ll start off with the web app. But let’s imagine that some the missing features (WRT the desktop version) turn out to be crucial, or that there’s some other reason why I want or need to use the desktop version. What are the pros and cons of the various installation methods? Do you have any other advice on how to run this on NixOS?
Edit: the web app fails to open most of the files I have to work with, stating that it needs to be recompiled with async support.
Were I you, I would go for repackaging the tarball-for-ubuntu, autoPatchelfHook alone should do the trick.
autoPatchelfHook is the first thing to try in packaging something precompiled for normal linux distros. If it doesn’t work,
buildFHSUserEnv is next.
Also note that
steam-run on a manually unpacked binary will generally work as a short-term solution if you need it running immediately. It’s using
buildFHSUserEnv with the FHS env used for steam games under the hood.
OK, I’ll have a go at
autoPatchelfHook. Is there a better way to discover dependencies than trying to build, look at the error messages, and try to guesstimate what packages might get me over this particular hurdle, and repeat until done?
The README in the tarball says
(C) 2018 Banana.ch SA
Execute the file start_Banana.sh to start Banana Accounting correctly.
If you want to install Banana Accounting in the /opt folder and
associate .ac2 extension in a terminal run this command:
Firstly, there is no
start_Banana.sh, but there is a
bananaplus with contents
#! /usr/bin/env bash
# autogenerated by linuxdeploy
# make sure errors in sourced scripts will cause this script to stop
this_dir="$(readlink -f "$(dirname "$0")")"
exec "$this_dir"/AppRun.wrapped "$@"
I guess that the install-in-
/opt option is going to be more problematic than running the start script?
ldd on the binary should help.
nix-locate can help you find the right packages, but chances are there aren’t too many dependencies. Most programs that do this kind of deployment try to minimize runtime dependencies in order to get broad usability and a lot chance of breakage.
Yeah, don’t install in opt… that’s not going to turn out well
Yup, just managed to hack my way through it and get something that seems to be working. Came across
nix-locate but, actually,
nix-autobahn provide a nicer interface to it (interactive selection with
fzf, filtering of the 99% noise).
Though openGL had to be found by hand.
But I guess that there are plenty of these tarballs which insist on doing just that, so I’d sort of expect something in Nix to cater for it. Isn’t there some function in there which automates dealing with things that want to be installed in
But I guess that there are plenty of these tarballs which insist on doing just that, so I’d sort of expect something in Nix to cater for it. Isn’t there some function in there which automates dealing with things that want to be installed in /opt?
Automate it? not that I know of, but if the program really can’t be cajoled into running out of a different directory, you could make it work with