[GNC-dev] About the "$HOME/.local" installation prefix

[Geert Janssens]

Op vrijdag 3 mei 2019 03:09:43 CEST schreef David Cousens:
> Hi John,
> 
> It was because of a number of posts in the forum, not sure whether DEV or
> USER around the time I reworked the pages which suggested $HOME/.local  for
> single user local installations of GnuCash . I think it may also have been
> specified the previous Wiki page I started from as well. At the time I could
> not find any better suggestions so I left it in place. My own preference
> has been to install in /usr/local or /opt system wide for production. If
> you use make uninstall from the build directory it seems to uninstall
> correctly from $HOME/.local as long as the manifest still exists as the
> paths to each file installed are specified
> 
Indeed. That's the mechanism in place to uninstall packages. It has a few 
flaws though. For this to work
1. the build directory is still around
2. the current state of the build directory still would install files in the 
same spot and at least the same files as the original install.

I have been bitten both ways (one of the conditions didn't apply any more).

These flaws are what triggered the creation of package managers. So in general 
I prefer installing via make install into a unique directory per installed 
application. That way the above pitfalls don't matter. If something changes 
such that make uninstall can't clean up, you can simply remove the complete 
installation directory.

> If I do a local temporary install, I personally install in a subdirectory of
> my home directory and add the relevant search paths to the front of the
> PATH environment variable . You of course have the problem with the order
> in PATH as to whether you search $HOME directories before or after system
> installed paths if you have multiple copies of different versions. Ideally
> in that case you could invoke a startup script which setup the PATH
> variable depending on which version you are starting up and where its
> resouces are located. I have used /opt and /usr/local for different
> versions but the same problem with ordering the search order in PATH
> arises.

You could also define aliases to deal with this, like
alias gnucash-my-build = /home/user/path/to/my/install/bin/gnucash

Then "gnucash" would run the system installed gnucash, "gnucash-my-build" 
would run your own

Or, as I would think most users would like to start gnucash from their Destkop 
environment's menu or application launcher, you can copy the gnucash.desktop 
file from <install>/share/applications to /home/user/.local/share/
applications.
If you then edit the file and change the "Name" value to say "My GnuCash" (and 
do the same for the Name in your language), you can start "My GnuCash" from 
your DE's menu or application launcher. You may have to log out and back in 
for this to work.

> 
> Python installs what it calls site-packages under $HOME/.local which seem to
> be user specific but most of the other data I find in the directory is in
> $HOME/.local/share which seems to be mainly user specific data for various
> packages.
> 
> The Linux File Heirarchy gives no real guidance for the structure of a users
> home directory apart from a reference to XDG and GLib conventions ( can't
> find any reference):
> 
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> 
> One stackexchange article suggested duplicating sections of the FHS under
> $HOME which seems a bit extreme.

I believe that suggestion goes with the concept of having $HOME/bin on the 
PATH. But the weakness of installing multiple applications in the same install 
prefix without the safety net of a decent package manager remains.

> If I did that I would be inclined to have a
> specific directory under $HOME with the /bin, /etc, /lib /share directories
> under it. I have an Applications directory for that purpose usually with a
> package sub directory under that which contains the above directories.
> 
I'm more in favor of this approach as well.

> For the little development work on GnuCash I do I have a separate structure
> again under my home directory which has an install subdirectory which I
> install to.

Same here.

> I have often wondered whether I am actually getting to the
> correct libraries by setting up the PATH variable (particularly if I forget
> to set it up). Then there is unsetting PATH when you want to go back to
> production work.

You shouldn't worry about setting paths for getting the proper libraries. 
GnuCash should take care of this itself. It's encoded based on the 
installation prefix you provide while running cmake.
The only reason to add something to the PATH is to allow you to simply type 
"gnucash" somewhere in a shell and that would then start your local 
installation. But even that's entirely optional. You could just as well start 
it by using the full path to the binary, make an alias as described above or 
move it up your path by adding a softlink from $HOME/bin to your gnucash 
binary.

Both of the latter options allow you to use a custom name for the binary so 
you can choose which gnucash to start.
> 
> Perhaps it is worth investigating the update-alternatives command  used when
> several python versions are installed, e.g.
> https://askubuntu.com/questions/315646/update-java-alternatives-vs-update-al
> ternatives-config-java. perhaps using this in startup scripts. Here the
> installed files are labelled with the version number and selected by
> setting a master and slave symbolic link groups which are setup with the
> "update-alternatives --set  name path" command.
> 
I think this is a bit overkill for gnucash. We don't have slave packages that 
need to be relinked. You can simply execute the binary you like (system wide 
one or your own build) and it will do its thing.
See the various options above for creating shortcuts or menu integration.

> Not sure what is the best location and structure for general users for a
> local installation though. I would be inclined to go for a directory
> labelled with a package name and version number with its own /bin, /etc,
> /lib and /share directories
A good option.

> and then prepend these to the PATH.
An alias, softlink or modified desktop file are probably better choices if the 
system wide gnucash should remain accessible.

Regards,

Geert