Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Tarballs (.tar.gz and .tar.bz2) are usually the compressed source code of a particular program - whereas RPMs (and TGZs and DEBs) are the compressed pre-compiled binaries. With tarballs, you have to compile them yourself; which for the newer Linux user may seem a little silly, but after a while, you realize you have A LOT more control over how something compiles.
Whereas binary packages (TGZ, DEB, RPM) usually already have the program compiled (with full capabilities - meaning no libraries have been forcefully left out of compilation) for your specific processor architecture, and can also provide dependency tracking (except for TGZ).
usually, source code is provided as tarball and distro specific binary as rpm. This is not always the case, but it is often the case.
The source code is not specific to a distro and is usually (note the usually again) directly provided by the upstream maintainer of the software whereas the distro specific rpm is USUALLY maintained by downstream maintainer.
You would usually prefer the tarball if the rpm is badly maintained or not present for your distro. The rpm is perfectly fine and easier to use if your distro is well maintained. You can have the source as rpm in most distros.
Preparing rpm is additionnal work from the community.
The developers do the source and a tarball is quickly done (one command to create a tarball).
As a result, there is a delay between the time the developer release the code and the distro maintainers prepare the rpm. Moreover, many distros don't have rpm at all.
Sometimes, you can have difficulties to find a prepared package for your distro, whereas the tarball is available from the developer.
Actually the developer doesn't care about the distro you are using and he just release the tarball.
This is the case most of the time, although from time to times the dev will provide rpm.
So, the tarball are widely used because they are useaable on any distro, whereas the rpms are widely used, but only in the rpm based distros.
If your distro is rpm based and you are not a developer, you should probably use rpm.
The most objective comparison IMHO still is Comparing Linux/UNIX Binary Package Formats. Source tarballs aren't in it though. While source tarballs can be deployed everywhere (provided build and runtime dependencies are available) it's an uneven comparison since source tarballs are not a package management format. If they where, they would clearly be lacking. If you don't want to read the link, and you haven't noticed any differences, let me ask you a few questions so you can find out yourself. Substitute tarball for package:
- What's the quality assurance of the package?
- Can you verify package contents?
- Without external means?
- Per file attributes like owner, group, access rights and MD5 hash?
- Do you need a compiler in your production environment to get your package installed?
- Can you verify package authenticity by GPG signature?
- Without having to download the sig separately?
- How fast can you get the OS installed on a pristine machine?
- Can you deploy a kernel or a set of applications uniformly across those w/o having to remember compiletime choices?
- Forgetting any dependencies?
- Can you scale both up to onehundred servers efficiently?
- Can you enumerate packages and contents easily (w/o having to resort to sometimes inaccurate tools like 'installwatch')?
- By installtime, category or size?
- One year later?
* If you say none of those matter you probably also say you're "not a big believer in automated dependency handling".
Many package-formats such as RPM are "compressed files" just like ... in fact they may actually be ... "tarballs." But a package consists of more than just the files themselves: a package also includes an install/uninstall script that is used when you install and when you remove the package.
It is historically the case that "tarballs" usually contain source-code and not binaries, but this is not mandatory. Likewise, historically most RPMs contain precompiled binaries, although source-code packages also exist.
The essential difference is that a "package" includes both the payload and an install/uninstall script, which the package-manager knows how to find and invoke.
The same idea is found in some Windows installers: you can sometimes "unzip" an installer to get direct access to the payload files. But the installer contains both the payload and the automated install/uninstall scripting that drives the pretty step-by-step display that you're so accustomed to.
Last edited by sundialsvcs; 04-29-2008 at 10:14 AM.