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

Question

I see all these links explaining packages and .debs... I know that... and there are many kludges to get tar.gz files working (eg: update-alternatives for Java or manually dropping the file in /usr/local/bin (or somewhere else, which I had deduced from hours of searching)). If packages are so smart, how are so few Linux applications available in packages or .debs/rpms?

I'm speaking as a new user; I know experts probably know it better (I think I can download a compilable version of Eclipse?). Like netbeans and chrome are .sh, eclipse is a plain, launchable directory, Java requires this update-alternatives business but I don't think it registers itself into Ubuntu/Debian's "programs list" (just registers as a command), etc. (I know these are sometimes available in repositories, but I'm just confused why download pages don't have proper explanations).

Long story short: If a download or compile a tar.gz file, how do I register it to the system? update-alternatives seems to register it as a command, in Ubuntu, it doesn't show up in the search bar. In Debian, I can manually add a shortcut to the GNOME 2 launcher. But what should I really be doing?

---

Edit:

So after playing around a bit more with the new solutions, I can sorta refine my "problem":

How should I manage my manually installed programs? Firefox and Eclipse are my only examples so far (I don't download a lot of stuff). They can both run out the box, which I like. Except, where should I be installing them? I see Eclipse has it's own instructions, but I'd rather do all my "manual packages" the same way.

1. After some research, I decided to put these programs into /usr/local/bin.
2. From how to install eclipse, I figured to get something to show up in the launcher, I need to put a xxx.desktop file in ~/.local/share/applications/. Does the name of this .desktop file matter?
3. Stuff with autotools (I look for a configure or unix/configure file) will work out fine. Some research points that I should use CheckInstall to keep track of all these.
4. I should use update-alternatives to register paths. From this java thread, it looks like I create a link from /usr/bin/java to /usr/lib/jvm/jdk.... When I install these "standalone" applications like Eclipse or Firefox, should I always link to /usr/bin/[app]? And if assertion 1 is true, I would be doing stuff like sudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

Are these instructions correct/a good way to manage manual installations? Are there any other steps I should follow? Other suggestions?

Answer 1

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

Answer 2

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.

Answer 3

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?

Answer 4

I would like to add that you can also symlink to ~/bin/ instead of /usr/bin. *.desktop files can be placed in ~/.local/share/applications/ or /usr/share/applications/. Only I use my computer, and I like to avoid touching system files (anything outside my home directory) myself as much as possible.

Of course, when you put stuff in the "home directory" counterparts, they won't show up for other users.

This is what's included in the default ~/.profile for debian wheezy:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi