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?


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?

  • 1
    Why not to seek for a *.deb package instead?
    – m0nhawk
    Commented Feb 3, 2013 at 9:18
  • @m0nhawk Can't always find a .deb file? Like on Eclipse's download page it's just tar.gz . Unless I'm completely missing it
    – Raekye
    Commented Feb 3, 2013 at 9:21
  • 1
    For Eclipse there are definitely exist a package for Debian (for Ubuntu). And I think that the best way to handle the *.tar.gz software is to create the appropriate package: *.rpm, *.deb etc.
    – m0nhawk
    Commented Feb 3, 2013 at 9:25
  • 1
    You need a .desktop file to have something show up in the menu. update-alternatives only works to prioritize your PATH.
    – tripleee
    Commented Feb 3, 2013 at 13:14
  • 1
    Your question is still about "what should I do to register new software with ______" where _____ is a particular desktop environment, and not "what should I do WRT linux" in general. Plus, maybe, an implied ignorance regarding the $PATH environment variable?
    – goldilocks
    Commented Feb 4, 2013 at 15:03

4 Answers 4


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

There could be many reasons:

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.


  • 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

  • Thanks for the detailed response. I looked into readmes, but I decided I didn't want to do something different each time. So after a lot more research, attempts, and frustration, I came up with a more concrete question/specification - see updated post.
    – Raekye
    Commented Feb 3, 2013 at 22:18
  • You're welcome, I hope it helps :) I edited my answer to address your updates. Keep in mind that there's no "One True Way" to do things (except if you're an emacs user). You have to go through trial and errors to learn, with time, the benefits and drawbacks of each of the different approaches.
    – rahmu
    Commented Feb 3, 2013 at 23:37
  • Thanks for the update! Certainly does. I'm guessing xxx.desktop generally works for GNome. What do you know about using update-alternatives to set the path?
    – Raekye
    Commented Feb 4, 2013 at 2:30
  • 1
    As far as I know, it's a Debian-specific way of dealing with generic software, like having multiple browsers or editors. (Ubuntu and Mint are based on Debian and have inherited this). Here's more if you're interested
    – rahmu
    Commented Feb 4, 2013 at 3:02
  • Great answer. One thing that is often necessary (or at least preferred) is to do a sudo make install as the last step (with a package you trust). That gives the process the permissions it needs to put things in system directories not owned by your user (like /usr/bin).
    – Joe
    Commented Feb 8, 2013 at 20:44

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.

  • "in the distro binary" <-- /me mutters something about source-based distros
    – njsg
    Commented Feb 3, 2013 at 13:07
  • Also, a problem with the XDG standard is probably that some upstreams don't care about that at all and distro developers are the ones providing their .desktop files, for that kind of tasks these are required.
    – njsg
    Commented Feb 3, 2013 at 13:08
  • I don't know if upstream developers should be concerned with that. I just mentioned XDG because it is available to the end user if you want to use it. A price of heterogeneity is that it inevitably puts a burden of responsibility on the user that they would not have with, eg, OSX. Some linux distros aim to minimize this more than others, and you are free to choose, but ultimately I think people who are really uncomfortable with that model should just plain not use linux at all -- I am not sure why they would want to in the first place, actually.
    – goldilocks
    Commented Feb 3, 2013 at 13:28
  • I've sorta formulated a better question - how should I manage my manually installed applications? Like Eclipse and Firefox, which generally run without complex dependencies (so I can set it up myself and download the package). They work standalone, as your or someone else mentioned, but I should I keep track of these apps, instead of leaving them all around my file system? (See updated question)
    – Raekye
    Commented Feb 3, 2013 at 22:20
  • Raekye: It doesn't make any difference to my point, which is that you don't have to do anything to manage or "keep track of" things you installed from source in /usr/local, except to the extent that you want to for whatever your purposes are. Beyond compiling and installing in $PATH, there is no universal linux registry because there is no purpose for such a universal approach. I'm assuming you are just worried you missed something -- you didn't. You un-tar, you configure, you make install. That's it, done. Anything after that is a matter of personal preference.
    – goldilocks
    Commented Feb 4, 2013 at 14:59

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?

  • "If all you want to do is run a compiled package, maybe add the binary path to your $PATH?" <-- I suppose any sane installation procedure (say, make install or the like) would at the very least install a symlink under /usr/bin/, if not install the whole thing under /)
    – njsg
    Commented Feb 3, 2013 at 13:09
  • Mostly, I guess it's due to me doing a lot of --prefix=/elsewhere to keep custom builds away from the normal tree.
    – Matt
    Commented Feb 3, 2013 at 13:44
  • 1
    Generally, tarballs using make install will install to /usr/local/bin Commented Feb 3, 2013 at 15:48

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .