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)
It is silly for us to ignore such a large divide in our community though. It exists, therefore we should look at it in depth so we can improve it and better the community as a whole. We shouldn't set off a battle cry for the entire community to come together if that's not really what's going to happen, at least not in the reality that i see. but then again my personal reality distortion field is out of whack this week.
The distroes are quite divided. How 'bout we look at what is specific to each distro so people can chose which is best for them. That is a better way to garner support from the outside community, doncha think? Don't leave them in the dark, that's what scares people away from Linux.
There are different levels of package management which often confuses the newcomer into believing (dogmatically) that one is better than the other.
The installable packages themselves have to have flexible dependency markings and coherent version markings. The low-level package tool has to be able to install and uninstall packages cleanly and repeatably. Seems like the dpkg/deb suite and the rpm suite are quite comparable here.
The package manager has to be able to build a requirements tree for a desired package, and then fetch all of the required packages to fulfill those dependencies on the local system. It should offer trust or signature verification to ensure only trusted repositories and trusted packages are used. The apt tool seems to be cross-platform, while non-Debian distros often spin their own service model here: up2date, Red Carpet, and whatever Mandrake and Lindows offer are each commercialized with some amount of sample access.
Lastly, the most important criteria, is the repository itself: it should contain packages which are clean and trustworthy. There have been cracking incidents, and there will be more. The quality of code between distro-produced packages and externally-produced packages can be as different as night and day. The package's meta-data and manifesting information can be crap, or it can be carefully constructed. The embedded installation scripts can be trivially exploitable or they can be carefully scrutinized against unexpected results.
Even if your package format is cool, and your package manager is cool, consider the repository. If the repository is not secure and offers poorly tested packages, many folks are going to unfairly blame it on the tools.
[
Are you smoking crack?
Having a compiler available on all of your systems to compile C code is far greater risk than the "threat" of getting trojaned builds from Red Hat.
Take your tinfoil hat off and breathe.
Conformity is the jailer of freedom and enemy of growth. -JFK
Believe it or not, like (essentially) all things, binary packages have a purpose, just as source packages have a purpose--platform agnostism.
Before giving me an explanation as to why you (read, the parent poster) in particular would not have a use for binary packages, allow me to explain why binary packages are useful. In the majority of instances, binary packages are useful when one is installing the userland on a system, or when installing a compiler, when you have no other systems to build the compiler on. Binary packages are also handy for systems where compiling from source would be inconvenient, resource-intensive, and time consuming.
Also, there are some proprietary applications that are not available as source, so a logical manner of packaging is with a standard binary packaging system such as RPM or dpkg.
Even NetBSD has its own binary package format (no, not the sets, those are for the base install and are just tarballs without package information).
All in all, binary packages are very convenient, despite the inconveniences caused by vendors who do a poor job of managing their package collection and dependencies. Binary packages are single files, smaller than source archives in most instances, and are installable in a uniform manner.
Let's not get into rogue "package vendors" who package trojans. They are the minority, and most reputable software developers release their own binary packages along with sources anyways.
I think I need a glass of water.
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
Because some people have older machines that take several days to compile large subsystems such as Gnome and KDE?
Because some people run dozens or hundreds of machine with identical configurations, so compiling the same package on every single machine is pointless?
Because companies prefer working against a known build of a piece of software for support reasons?
Source distributions are far from a panacea.
Is that the rpmlib API is almost completely undocumented. As GoRK pointed out, management tools such as apt, rpmfind, up2date, etc. are far more important than the underlying package format.
But it's very difficult to create those management tools for RPM when the API is a "black art" known only to a few. Questions on the RPM mailing list/newsgroup will generally be met with the advice to "use the source, Luke"--all several hundred thousand lines of it!
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Obviously, for large software packages, you probably don't have time to read every last line of code.
That is the understatement of the year. I would dare say that in order to read and understand a program that is on the order of five million lines, it could take you a year or two. For a non-expert programmer (or even an expert with no operating systems experience) it could take forever to just begin to understand something like the Linux kernel source.
But what I generally do is untar the source and then grep through it for suspicious things.
That's great if you know what you are an expert programmer (and if you think that a simple grep will help you that much.) But what of the small business that doesn't employ you? Do they need to perform that same review? Of course, they could skip it and just compile the thing, but that is the same as just using the binary packages!
You may as well just hang your Linux box out on the net with 500 open ports and no firewalls.
Baloney.
Because a well-hacked program will allow the hacker to get at your data, firewall or not.
A well-hacked program will be completely invisible to you, as well. Your grep methodology is too simplistic to catch any sort of sophisticated trojan. Even if you were to laboriously go through the code, line by line, you still wouldn't catch anything but the most obvious of hacks/problems.
The only way you can be completely sure is to read the source.
No, the only way is to not run it. Software is not a mathematical formula that you can "prove". Large programs are horribly complex, as you most likely already know. Binary packages serve a very useful purpose for many people. If you choose not to use them and to perform some limited form of code review, then that is great for you, but don't try to demean anyone who doesn't do the same.
Actually, the point goes much further than this. If you are on a RPM system and you lose control of RPM, either through library problems or dependencies, or what have you, you suddenly are robbed entirely of your ability to control the packages on your system, usually including the ability to fix the system itself.
.deb seems to be a far superior package format to recover from catastrophic failures in system utilities such as the package manager. Of course, as you may have ascertained from my comment on cpio, I have experiences precluding bias. ;)
This is not something anything but highly technical users, or even faint of heart, will encounter. However, it is something that has undermined my ability to recover from catastrophic failures on machines with RPM that do not have CD or network access. I have even been reduced to binary manipulation of RPM files to extract the cpio compatible archive (not a task I would undertake lightly).
In contrast, with Debian packages, I have been able to rebuild a machine from scratch with ar, tar, and gzip, which are extraordinarily unlikely to break. Even in the event that they are unavailable, one can copy them to lightweight media, statically compiled, and then they have no real dependencies. Even if dpkg or apt fails (the latter more likely than the prior, in my experience), it is almost always possible to recover from catastrophic mistakes.
In summary,