Slashdot Mirror
Binary Package Formats Compared
jjaimon writes "There is a document on different package formats used in Linux/Unix systems. Worth reading." Another reader sends in this guide to creating Debian packages which seems apropos here.
← Back to Stories (view on slashdot.org)
Joey Hess created that document (at least the first revision) around 1998 IIRC, so it's not so much new news (guessing it's been posted here before, but probably around then as well)
Best thing about RPMs? GPG signatures built in. Try rpm -K whatever-x.x.x.rpm next time. Second best thing? rpm -Va.
Get your own free personal location tracker
The binary distributions usually come with a way to compile your own binary packages if you wish to inspect the source code. Just download the source RPMs or use "apt-get source". The "binary distributions" are generally binary and source distributions where you can choose whether you use prepackaged binaries or compile your own.
Similarly, I could install a Debian binary package if that were all that existed for my particular environment, with a simple
(I digress, simple may be relative)
On the other hand, since RPMs have a special binary header, the lazy would be forced to install RPM and Berkeley DB on non-Red Hat-machines in order to build an RPM package. Though it is possible to extract the gzip'ed+cpio'ed data in an RPM without using rpm.
So, in my view, Debian has a bit of an upper hand in simplicity, from a technical standpoint, but not by much.
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
> The TGZ packaging scheme (also mentioned in the article, along with RPM and DEB)
.tgz is not really a package format. .tgz (.tar.gz, or a compressed tape-archive) is no more a binary package format than .zip is for windows.
/package/install.sh script in the tarfile which is run with a bash shell after the files are extracted to do any command based setup, but that is it.
.zip file that states 'uncompress this file exactly here C:\windows\system\whatever\foo.bin ' .tgz can do.
.zip and .tgz do great.
> just... Well... Sucks.
Not intended as an attack aginst your comment (You are fully correct, it sucks) but to clarify a point:
Slackware created a rather elegant hack at the time, of having a
Imagine if you will, a
That is all a
This is why it supports no dependencys or checking, because its just an archive file.
Technically speaking, this isnt a package format as much as a creative way to run a shell script after extracting some files.
* I realize you were just replying to the articles claim that it is a package format, and from your own experences. I just wanted to explain why your experences sucked... It was more of a design flaw to use an archive as a package format, then the package format sucks.
From an archive stand point,
RPM's are relocatable (at least most, if not all of the packages Mandrake distributes are; hardcoded directories are against Mdk policy and caught by rpmlint). Just edit your .rpmmacros and set macros like %{bindir}, %{libdir}, etc.
Here is the link to googles cache of the site:
CLICK HERE
"If ignorance is bliss, why aren't there more happy people in the world?"
This is why debs are signed. Run MD5 on the deb you download and compare it to the one that Debian shows. If they're not the same, delete the package. Don't trust the Debian packagers? Then why the hell are you using their software?
The RPM/DEb ideas are really good. The main problem i have however , and don't really know how can be solved is combining binary packages with source code packages (eg. when you compile you own X). When the time comes and you want to update , let say Libc, then you will be unable to do so because the dependecies include almost every package.
Or when you compile a program that is listed as a dependency to another program , you can not install that other program because compiling from source code does not update the RPM database.
It seems that binary packages are only good when you stick to what your vendor offers you.
Using --nodeps is not the solutions because it defeats the whole idea of depencdency tracking.
Slashdot Sig. version 0.1alpha. Use at your own risk.
I have only recently come across the freshrpms.net site, and I have been amazed at the work that has been there. The site helps the user to find, from a list of supported packages, the most recently rpm packages available for their systems. This site along with rpmfind.net, and tuxfind.net is what makes the RPM packaging system so successful.
I have on the past thought about changing distros, from Red Hat to lets say SUSE, Mandrake, Conectiva, etc, but I haven't mainly because of their support (at the time) for rpm packages was not very good.
Is RPM the best solution for the person who is looking to install software on their Linux box? I have my complaints, but since when does the best solution for a problem is the one most suited for the job?
I'll bite.
/ distribu tions/Mandrake/9.1/contrib/RPMS/kismet-2.8.1-2mdk. i586.rpm /var/cache/urpmi/rpms/kismet-2.8.1-2mdk.i586.rpm
For a desktop linux distribution, I run Mandrake. Currently, I'm running Mandrake 9.1.
Let's say that today, I want to install a common package that I don't have, but want to use, like kismet, the wireless sniffer (http://www.kismetwireless.net).
So, this is what I do:
# urpmi kismet
and how long does it take?
# time urpmi kismet
ftp://ftp.club-internet.fr/pub/unix/linux
installing
Preparing...
(Lameness filter hashes)
1:kismet
(Lameness filter hashes)
3.61user 1.13system 0:28.03elapsed 16%CPU
Yeah, that's 28 seconds.
Now you, compile it from source. How long did it take?
Now, I realize that kismet is something that someone else packaged up specifically for Mandrake 9.1, and it happens to be in the contrib section on a mirror for me. But, so is tons of other *common* software, and it's all that easy to install (yet, full dependencies included).
Of course, if I want to install something that isn't built for Mandrake 9.1, I can compile it from source just like you. But that's not slower either. In fact, if I spend an extra few minutes making an RPM out of it (granted some sources are harder to make into RPMs quickly), I can not only install it easily on this and any other Mandrake 9.1 machine I want it on, but I can also uninstall it, and upgrade it, with full dependency checking.
Compile everything from source? Hah!
The constant changes, in path structure in RedHat even between close number releases is not a good thing. It is more akin to a Microsoft like tactic than sensible advancement of an OS.
Perhaps a killer app for linux would be a Pathmaker that reads dependancy requirements goes out and checks the install paths before you ./config. Similar to gdb but easier to step through. Then it could help identify and rewrite any path errors in the source for the user. If the software determines that you do not have a required library then it could help the user to install or see if installing it might cause havock.
The current state of free software for Linux is becoming more and more difficult for the ordinary user to deal with. A logical tool designed to help the ordinary user to use source would sure be great. There are great dev tools in Kde and Gnome but there is a severe lack of a sensible integated install tool for non-coding users.
OH THE SHAME I fell off the wagon and use sigs again!
I (author) am currently enroute to Norway, only found out I was slashdotted in the airport. I don't really understand why they posted it today, and not some time in the past 5+ years.. Anyway, I will respond to anything worth responding to sometime later.
see shy jo
> Why? A compiler is only a translator. How is the ability to translate an arbitrary C program into assembly going to aid an attacker? The attacker could just as easily precompile the program themselves.
...unless the attacker's computer doesn't have the same architecture as the target machine. Linux and the *BSDs all run on a wide variety of platforms; if you were making a max-damage virus, being able to transport the source kit to the targets and make the executable locally, regardless of architecture, would be a good feature.
Alien allows you to convert LSB, Red Hat, Stampede and Slackware Packages into Debian packages, which can be installed with dpkg
Not sure how well it handles dependencies and such, though.