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.
- After some research, I decided to put these programs into
/usr/local/bin. - From how to install eclipse, I figured to get something to show up in the launcher, I need to put a
xxx.desktopfile in~/.local/share/applications/. Does the name of this .desktop file matter? - Stuff with autotools (I look for a
configureorunix/configurefile) will work out fine. Some research points that I should useCheckInstallto keep track of all these. - I should use
update-alternativesto register paths. From this java thread, it looks like I create a link from/usr/bin/javato/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 likesudo 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?
Best Answer
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.Notes
configurescripts 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.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/binfor 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/binhas the advantage of already being in your PATH. If you want to use another directory (like/optas 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