-   Linux - Newbie (
-   -   Why tarball is better than rpm (

maxy7710 04-28-2008 07:48 AM

Why tarball is better than rpm
Why Tarball is better than RPM????

I have installed both of them & do not find any differnce as of now, then why do linuxites prefer tarbal over RPM.

indienick 04-28-2008 07:52 AM

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).

Agrouf 04-28-2008 07:54 AM

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.

maxy7710 04-28-2008 08:18 AM

thnks guys
thnks guys for the input but except from the control how to compile it, are there any more reasons for its wide use throughout the communitty.

bigrigdriver 04-28-2008 08:31 AM

Upgrade from an older version to newer version of an rpm package is as easy as 'rpm -U'. I don't know of any such mechanism for upgrading a source-based package from one version to the next.

Applying patches to rpms is easier than to source packages.

Uninstalling an rpm is much easier than uninstalling a tarball.

Agrouf 04-28-2008 08:54 AM

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.

unSpawn 04-28-2008 11:46 AM

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".

maxy7710 04-28-2008 11:52 PM

Thnks Guys thank you very much.........

sundialsvcs 04-29-2008 09:12 AM

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.

All times are GMT -5. The time now is 02:52 AM.