How to truly install a tar.gz file on Linux - how to manage manually-installed (or standalone) applications?

Why are a lot of apps not available in package repos?

There could be many reasons:

• No one bothered to package the app.
• No one is allowed to package the app (like Oracle insisting on being the only one to distribute Java).
• The package is published under a license that contradicts the distros values.
• ...

There's no one single reason. If you'd like to see your favorite app in your distro's package manager, you should treat each case separately. Try to get in touch with the devs (on an IRC channel or a mailing list for instance) and ask how you could help packaging.

How to install a tarball?

A tarball (.tar.gz package) could contain anything. Until you actually open it, you have no way of assuming how to install it. Again, each package should be approached differently.

Look for documentation! Any (semi-)decent package will provide instructions on how to install the application. Your first reflex should always be to look for a text file called README, INSTALL or something like this. Checking out the website of the publisher might also help.

Since every package is different, there's no universal way to process every tarball in the world. That's like asking for a recipe which works on all the ingredients in the world. Not happening.

A good knowledge of your system, your distro and your desktop environment will help, so, if this is reassuring, things will look more and more predictable as you spend time in the linux world.

A special case: Autotools

As projects grow bigger, they need to provide easy ways to move from source code to binary to full install on the system. This is why they ship with an embedded build system, a collection of scripts to do the necessary.

In the Linux/Open Source/Free Software world, one build system got a wider adoption: GNU Autotools. If you ever deal with a(n open) source package, there's a solid chance that you'll be using Autotools.

In the simplest case, here's how to install an app packaged with autotools:

• ./configure: A script that will generate the Makefiles corresponding to your system (it also often checks for the availability of dependencies).
• make: Compiling the source code according to the Makefiles generated earlier.
• make install: Copies the binaries to the appropriate locations, creates symlinks, and any other step defined by the developer.

Notes

• configure scripts usually have a lot of options, like which compiler to use or how to define the target directory. If you need flexibility, it's worth looking at ./configure --help.
• Even if you're sure it's Autotools and you know it really well, always start by reading docs (README, INSTALL, ...)

Answer to the update in the question

What you're asking for has no definite answer. Everyone here might have an opinion on what constitutes "good practice", but at the end of the day, only you can find what works for you. If there was an easy answer, you wouldn't be asking the question. Your distro would've answered it for you.

This being said, here're a few personal remarks.

• On my system, I reserve /usr/local/bin for the packages installed by my package manager. Everything I compile/install by hand goes in /opt. This is a detail but it helps avoiding major headaches when dealing with several versions of the same program.

• xxx.desktop, and GUI issues in general, are specific to the desktop environment you're using. If it works for your system, great. But it cannot be generalized to all the environments available on Unix.

• /usr/local/bin has the advantage of already being in your PATH. If you want to use another directory (like /opt as I suggest), be sure to include it in your PATH. If you don't know how to do it, open a terminal and execute the following in a terminal (not the prettiest way to do it, but without knowing anything about your system, I cannot suggest anything else): echo 'export PATH=$PATH:/opt' >> ~/.bashrc

I think you have to clarify with yourself what you want to "register" it with.

To explain -- and I'm not trying to be smart-alecky -- "linux" is, of course, the kernel, and the kernel neither knows about nor has any interest in any of the userspace software on your system beyond init. So what are we talking about here?

You mention a number of different distros. I sometimes build software from source even though it is available in the repository because I want some configure options set that are not set in the distro binary. The only problem I have with this is that if the package is a prerequisite for something else, I do indeed have to register this with the packaging system in order to avoid accidentally installing the distro package on top of the one I built. On fedora/rpm based systems, this is done with rpm -i --justdb <package>. I don't do this on debian/apt based systems; instead I just force installs as needed, which is perhaps lazy -- there looks to be a nicer way of doing it, by creating a dummy package that pretends to fulfill whatever prereq. That is sort of along the lines of m0nhawk's suggestion of actually creating a package from the .tar.gz source -- except quite a bit simpler (I'll be honest and say that I do not at all like m0nhawk's suggestion).

It seems that you have some other issues besides the one with the packaging system. It is not clear to me what those are, though you mention the desktop environment (eg, Gnome). These are heterogeneous, so there is simply no one answer to the question, "how do I do this on linux" -- it is not even a question of "how do I do this on ubuntu" or "how do I do this on gentoo" -- it's a question of "how do I do this for the gnome desktop" or "how do this on the XFCE desktop", etc. To my mind, the only issue there is the matter of launchers you mention, which I would like to believe that every DE provides a simple means of doing this (but it won't be exactly the same, because they are different). There is also possibly the issue of having something provide a default for dealing with files -- I think that question is "how do I register a command with my file browser" (and file browsers on linux are a heterogeneous collection too).

Then there are services, which are managed by the init system (eg, systemd or upstart). So this question is actually a series of related questions relating to, potentially:

• the packaging system, eg, apt or yum
• the init system, eg, systemd or upstart
• the desktop environment, eg, kde or unity
• the filebrower, eg, nautilus or konqueror
• ?????

Part of the reason there cannot be one simple unified solution (although the XDG standard may provide some parts of such) is that "linux" is not one simple unified operating system and I imagine the vast majority of its users prefer it that way. I often don't use a DE at all, and I never use the file browser they come with, etc.

Again, I am really trying to be helpful with this and not just pontificate: if there are problems you want to solve here, you will have to consider more precisely what those problems are and what software is actually involved with them (beyond just "linux") if you want to solve them.

I think the basic reason for your overall problem is that a Linux system on it's own doesn't contain a "registry" as such. An executable file is all you really need for something to run. If you don't want to specify the full path to the executable then most shells will look for them in the directories listed in your environments $PATH variable. It can get a bit more complex with linked libraries and so on but normally you don't need to delve that far.

Different distributions of Linux have standardised on various filesystem layouts and package management systems, therein lies the problem. The Redhats use rpm, Debians/Ubuntu use deb packages. Arch went it's own way as well. From a software projects perspective, unless you want to be included in a distribution, your user base is entirely in one distro, or a commercial product that's aiming for ease of install for everyone, they're probably the only points you start looking to building various packages.

In actual fact, a source tar.gz that builds with gcc is probably the best definition of a common "Linux package". A Linux kernel with some GNU utilities and GCC just about the common denominator between all the different flavours of Linux based operating systems you can get.

I wouldn't go as far as saying "so few" things are available as packages because something specific you're looking for isn't. (or maybe the distributor has chosen not to bother with all this package fuss? Like Chrome and it's own update process). There are so many packages around for so many different package systems for so many architectures for so much free software its not funny.

If you have built something that is not supplied as a package for your distribution of linux, or supports the option to build as package, the best way to "register" it as a real package is to build a package for it, defining where all the files should go based on the package system you choose and install it that way. Be a soul and contribute your packaging work back to the project so others can benefit from it.

There are various guides the web about building packages. Debian being one of them.

If all you want to do is run a compiled package, maybe add the binary path to your $PATH?

If you're doing something else, what is it?