When installing local applications, there are multiple options depending on how you want to access and update. Also should be noted that some methods look more like the system you already have and some are more ad-hoc. I would suggest that the "best" solutions are the ones that make things easier to manage.
I have split this answer based on the number of packages to make custom installs for. The splitting is based on my own experiences. These experiences weigh the time it takes to manage the packages and the risks of messing up something. I do not mean that I have the knowledge of common standards but mean this as a reference point to look when making the decision.
For only few packages,I would to put add-on packages in
/opt, where they are out of the way of everything else so nothing can mess them up and they can mess something else up. This is the method I use on my NAS. This method however keeps the binaries off your PATH, so you will need to add them manually. This works well if there are only few packages to install, but becomes quite a mess if there are many.
Updating here is quite easy as you simply overwrite the directory.
- fast to setup
- no chance at affecting other parts of the system
- uninstall is as easy as install
- Becomes rather tedious if the number of packages to install is large
PATH look messy
For more than a few packages, I would recommend using the
/usr/local/<your package> and sym-linking the executable from
/usr/local/sbin depending on if you need root privileges. This saves you from changing your PATH every time something new is added so the PATH stays clean. This is the method I use on my Arch laptop for all non-pacman packages and AUR packages.
Updating is done by overwriting the package directory and checking that the symlink is still valid and fixing if it isn't.
- Doesn't make
- Doesn't affect the base system
- Still very simple to remove all add-ons and return to a clean base system
- More work to setup
- Removing only one package has some searching to do
For many packages. As this isn't the case you are wanting I will keep it brief. I would recommend splitting the package into
share, etc. and installing them to
/usr/local. This is to keep the structure clean. You can also specify who can write where and more. For example you don't want people other than root modifying the executable.
Here the updating gets a little more tricky as you need to write to more than a single directory. I would recommend packaging the whole thing and letting the package manager handle the rest.
share directory itself is for architecture independent files as noted in Faheem's link and the architecture dependent files should go to