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)
Instead of drawing attention to our differences and what keeps Linux distroes divided, we should be emphasizing what we have in common. Let's see some articles on our solid kernel code, the friendly and knowledgible community, and the capital "F" in Free!
Boromir, son of Faramir, King of Gondor and Minas Tirith
Why don't you just ask what everyone's favourite distro is?
Apt-get, no emerge, no make world, ARRRGH!
...considered a gross misfeature? Count me in.
No matter how many "packages" I see. Still love slack-packs the best.
Come with everything you need, esp created to make you learn what the hell your doing before you do it.
argan0n
You guys came out.
:)
You're getting slow. Must all be compiling right now
It seems to me, if you want to cover everything, you would put a debian package inside a RPM.
Why? I have no clue, but you could if you wanted all the features. Kind of like putting a roll bar into a SUV, so that you can start amature racing.
=================
Unix is very user friendly, it's just picky about who its friends are.
I don't understand why so many ostensibly clueful people are so enamored with the whole concept of binary distributions. One of the biggest selling points of open source software is that it is precisely that -- open. You can download the code, look at it, read through it, and then compile it yourself so that it is completely optimized for your individual CPU. You can also make sure that there are no virii, worms, Trojan Horses, etc. that you are about to introduce into your system by reading the code before you compile it.
.. a dead giveaway that somebody has tried to slip some kind of a backdoor into the code. If I find something like that, I rm -rf it and forget it. You can also search for calls like gets(), strtok(), fopen(), and other well-known security risks and fix them if you feel like it.
Obviously, for large software packages, you probably don't have time to read every last line of code (I know I certainly don't.) But what I generally do is untar the source and then grep through it for suspicious things. For example, if it's not a networking application, then I'll usually grep for system calls like connect() or bind()
All of this goes away if you download and install binary packages. You may as well just hang your Linux box out on the net with 500 open ports and no firewalls. You may as well be using Windoze!! Because a well-hacked program will allow the hacker to get at your data, firewall or not. And with binary formats, you have no way of knowing if the software you install is safe. The only way you can be completely sure is to read the source. As a side benefit, you can pick up a lot of programming tips as well.
To paraphrase Bob Dole: Binary packages -- just DON'T do it.
First time I've ever seen guys compare packages and size doesn't seem to matter.
Not compared: my favorite package
* Please do not read my signature.
While at first glance it seems heavily slanted towards Debian's .deb packages (Its first and contains more "YES"'s than the competition), as a developer I'd be far more concerned with basics like "market penetration" than whether it allows me to assign my package a "priority" over other packages.
I suppose it might be of use to folks building their own distribution, but I expect thats a pretty short list.
But personally, I tend to grab the source when I'm adding something that RedHat didn't include (or seems woefully out of date)
You are in a maze of twisted little posts, all alike.
I'm sure this will erupt into a huge flamewar like the last time it was posted when all it boils down to is that it doesn't really matter much to end users about the package format as long as the installation and upgrades are made easy. For me, aptitude/apt with .deb packages has proven easiest, but a lot of people like apt with RPM or RedCarpet or rpmfind or whatever else is out there. Lindows users use the 'one-click' install thing not even caring that there are .deb's behind the scene.
Part of the reason, I think that the deb format has always seemed to hold together really well is that most all of teh deb using distributions are so tightly integrated with the main debian distribution that packages are always totoally interchangeable (and are very good to notify you when they will not work.)
RPM on the other hand is adopted by many different and sligtly incompatible distributions that often finding the libraries and applications you want to install is difficult not because RPM's are hard to find but because RPM's that work in your current setup are hard to find.
This is simply why the management tool(s) on both ends (creating packages and maintaining installed packages) matter way more than the package formats themselves. Deb's are very compicated but sometimes easier to deal with because of all the good debhelper tools. RPM's are most often more 'hand-crafted', but they are a lot easier to create from scratch for many people.
The thing I really hate about deb's is the lack of signature verification. It's absolutely central to the development/upload/build process but until very recent efforts has been a total pain to use on the installation front. There is no good reason for this either.
~GoRK
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.
[
For example, a quick overview of most packages used by Linux user consist of a seaty nut sack and a slightly left-leaning penis.
I love Gentoo, but I can entirely understand someone not wanting to spend 18 hours compiling OO.org or KDE. Or even half an hour getting Moz-Frirebird. All I know about the Gentoo reference binaries is that they exist. But they weren't covered and since they seem to be the (distant) second choice for the Gentoo devs, I doubt it is as easy to use as portage.
Because all those optimizations don't mean squat when most computers are not maxing the CPU on a regular basis anyway. Also, portage is not a silver bullet. While it's got a very good system for handling a whole lot of things (especially cool stuff like being able to peg versions or inject versions if you want to roll something by hand), it's not nearly complete. Look at the lame way it handles config issues by just post-poning that to etc-update, which isn't remotely user friendly, imho.
I do not have a signature
Just depends on how you shuffle them around.
E.g. Packages on FreeBSD are usually tarballs as gzip or bzip2. "Meta" data is usually the +CAPS files. Validation is usually an external MD5 checksum.
Too bad there are so many distribution differences that one (simple) standard can not be made to compete with the (possible?) ease of (*cough*) W*****s installers, but that would be like saying, "why can't we all be the same blood type."
Gentoo is bad for the environment, since a computer uses more power when the processor is at work.
:-)
This means that using Gentoo is aggravating our problems with long-term storage of nuclear waste as well as introducing fossile carbon dioxide into the atmosphere.
Additionally, source code is generally larger than the equivalent binaries, so it is a waste of bandwidth to download Gentoo, which also is a waste of energy in the long run.
So, for the sake of our children, from whom we borrow the earth, use Debian GNU/Linux.
Click here
8 J: www.kitenet.net/~joey/pkg-comp/+&hl=en&start=1&ie= UTF-8
>> or for those with text browsers or aol
http://216.239.37.104/search?q=cache:x0Hrwxt537
Have a nice day
The site appears to have been slashdotted. Can anybody provide mirrors or summaries?
;)
Just like every other Slashdot reader, I'd like to read the article before I post a comment
This space left intentionally blank.
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)
What Linux really needs is a dir-independent application running /usr/bin to /usr/local/bin). Most packages, including g++, configure
system. Imagine a package of...oh, say, g++, where g++ runs properly
even if you move the whole g++ package to a different dir (say from
themselves to run in one location, and they'll get confused if you
move 'em.
Some packages (eg Tomcat) let you move them and they'll still
work...but only if you set an environment variable (eg TOMCAT_HOME)
so that Tomcat now knows where it lives. In a proper environment, an
application could easily & consistently know where it currently
resides on the filesystem *cough* OSX *cough*.
What Linux needs is some standard 'run-app' script that would inform
a package of its location. For instance:
% run-app tomcat
Run-app would be simple, say, the following:
#!/bin/sh -f
$app = shift
$location = `which $app`
env {$app}_home = $location $location/bin/app
That would enable Linux to devise a package format (or better yet,
improve rpm, deb, etc) for more flexible package management.
A package would no longer need to place its binary, libraries,
manpages, etc. all in hardwired locations in the OS...it could just
leave them in its original dir. (or maybe create a 'obj' dir that you
can remove if you wish to clean up the package.)
Practice Kind Randomness and Beautiful Acts of Nonsense.
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 there are folks that I do trust. I don't trust the latest nightly build of Mozilla, but I do trust the most recent stable release after it's been out a week or so.
You see, I know there are folks out there like you... so I don't have to be like you too. Enough hobiests and security folks will bang on popular newly released code to pacify my concerns. For specialty apps coming from unknown sources, care is taken and sourcecode reviewed. But, for code from the likeness of a major OS distributor (RedHat, Debian, etc) or a major code project (Moz, Apache, etc), I don't have to bother.
I want it fast and pain - free. Binaries please.
Support a few technologists in Washington.
Instead of drawing attention to our differences we should be emphasizing what we have in common.
Yeah!
Cause since when has using direct comparisons for determining
the best method for a process worked for anyone?
"You worthless post!"
-Shakespeare, 2 Gentlemen of Verona, 1. 1. 147
The list does not analyze autopackage. Despite it's really recent, it has some interesting features, and as far as i tried it works really well.
-- "If A equals success, then the formula is A=X+Y+Z. X is work. Y is play. Z is keep your mouth shut." - Einstein
Security is always a tradeoff between the effort required and the risk entailed. SSH is more secure than telnet. Even more secure is making all of your employees carry around OTP calculators, but most places don't do this because for them, it's not worth the effort. At a certain point, the "price/performance" tradeoff curve of security starts to get very steep in the direction of "price", and the only way to get 100% security is to have 0% usability (as often noted by the example of unplugging the computer and encasing it in concrete).
So, how much do you need to trust your packages? Do you have enough work and not enough top-secret data that you can trust the package maintainer, the upstream maintainer, and your copy of MD5? For most people, the answer is "yes". This does not apply to X Random Freshmeat App; if you're downloading a new program and installing it yourself, you should check it out first (if you have the means), since sometimes even good authors do things that are unintentionally destructive. But most people can afford to trust that a package which has been around for a while and comes from a reputable distributor is reasonably safe, especially if they're doing the work of 3 people, maintaining 5 platforms, and just trying to keep up.
Unless you're in a situation where many people want your very important data, you can usually afford at least a little well-placed trust. Otherwise, just keeping up with updates is going to consume an inordinate amount of your time, and the rest of your duties will suffer.
WMBC freeform/independent online radio.
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
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.
Definitely one of the features which makes Linux a powerful OS. A good and well-configured packaging system can be a blessing, automagically resolving dependancies or at least telling you where and how things will fuck up. The problem with package managers is that there are quite a few of them around. Normally, diversity would be a good thing but those package managers don't seem too willing to process eachother's packages...
For example, RPM packages are almost common these days; most open source software has a few packages ready to be implemented. Pretty much the same thing with Debian packages, because of the large userbase. Chances are that a few hours after the release of a major product someone has made a .deb somewhere, ready for you to install. However, if you'd look beyond these two packaging systems, you'd get a few nasty surprises...
The TGZ packaging scheme (also mentioned in the article, along with RPM and DEB) just... Well... Sucks. Or at least in Slackware, I don't know if any other distributions use it differently but lets use Slackware's TGZ system as an example for now. What's wrong with it, you ask? First of all (and possible the foremost reason) it's almost unused. Apart from the Slackware packages itself, I've never seen anyone distribute something in the TGZ format which worked. That excludes the few things which I found and simply refused to install. It doesn't do dependancy checking, conflict-checking, heck, it doesn't do anything or so it seems. I'd continue but ranting about the bad parts of Slackware isn't the issue at hand.
The issue at hand are the two remaining package systems, which might be technically sound and quite useable, but they still won't have allot of use. Who here has ever heard of SLP and PKG packages? And even then, who here knows of any major applications which distribute their software using those package systems? Sure, SLP and PKG might be a dream to use, but without any actual packages to install, they're (possibly sadly?) not really of any value.
Which brings us back to RPM and DEB, apparently two of the most common systems, courtesy of Red Hat and Debian. Looking at the list of summed up data, it's really not a miracle those two are more common: Both support mostly options listed, both are backed by a large amount of users/developers and both are relatively easy to use, yet still distinct. Perhaps a system which allows multiple systems to cooperate (regarding dependancies and conflicts and the like) would be a nice compliment to both RPM and DEB?
Hate me!
Comparing Linux/UNIX Binary Package Formats
This is a comparison of the deb, rpm, tgz, slp, and pkg package formats, as used in the Debian, Red Hat, Slackware, and Stampede linux distributions respectively (pkg is the SVr4 package format, used in Solaris). I've had some experience with each of the package formats, both building packages, and later in my work on the Alien conversion program.
I've tried to keep this comparison unbiased, however for the record, I'm a fan of the deb format, and a Debian developer. If you discover any bias or inaccuracy in this comparison, or any important features of a package format I have left out, please mail me so I can correct it. Several people have already done so. I'm also looking for data to fill in the places marked by `?'.
And the rest as far as I am concerned is utter bollocks. Well in fact the opening paragraph was utter bollocks, but I included it for the sheer and utter hell of it. And to be honest, the second paragraph wasn't much better, though it seemed to have a nicer flow to it, and at least admitted their degree of bias.
Um.
./configure script connects to a remote server giving it a shell. Running ./configure as root makes this potentially even more destructive. The ./configure script is the last you audit for security holes, no?
Yes, and it is completely impossible for users to (gasp) compile their trojans elsewhere and FTP them over?
Also, are you saying that you're compiling your stuff as root? Bad idea, since compiling software does not require root priviledges. A better idea is to compile your software as a user, and then "make install" as root through sudo.
There have been cases in the past in which open source software source code has been backdoored, so that running the
Sure, you could argue that "make install" is backdoored, but it's always a good idea to check exactly what scripts you're running through "make install" anyway, since that's done as root.
Run as little as possible as root, and don't fool yourself that chmodding user-space programs not requiring root privileges is somehow improving your security.
All of these formats could be done better. The OpenPackages project had a design project underway to consider the features of an ideal, multi- platform package format early last year but it seems to have died from lack of input. It'd be great to see it get a breath of new life. If nothing else, this article could serve as a starting point for what we do and don't like about current formats.
I can't understand what you saying, is that in foren langage so i need to change my langage? Pleese i just look for girl!
No matter how many "packages" I see. Still love slack-packs the best
Exactly how many of these "packages" do you see in a day?
And of all of them, you like the slacked ones?
are better than packages because you get more control over what is installed onto your file system. If you really want to the slight advantage that package formats provide over ports, use SRPMS. You will have some of the customizability of using ports and all the features that RPMs provide.
I'm primarily a Mac user here, but can someone please explain to me why the Linux equivilent of InstallShield(or VISE, or anything else like that) hasn't been created yet? While it isn't the best solution when you want to deal with versioning, dependancies, and top-notch security, it still seems silly that such a program isn't around, when it's obvious that most everbody that isn't tech-head wants such a program. Is there really such an evil reason that people can't have simple, easy to use installers on Linux?
I'll dress up and play with football if girl likes that. I don't have pencil in my neck. Promise! I used to have Star Wars things. But not legos, sorry.
strtok() is a bad animal because it modifies its input string (inserts lots of null pointers between the fields), and there are apparently lots of C programmers that don't know this. If you think that you get your input back pristine, all sorts of problems can arise (null pointer dereferences, stack-thrashing, undefined behavior, etc.) If you don't think that strtok() is dangerous, you obviously haven't lost an entire data center to it.
MSNBC is spouting a raving review of this brave new Linux distro. And best of all.... it's Debian-based. YeeHaw!
While I understand your logic, there's a HUGE hole in your reasoning (besides the ones already commented upon.)
:o) and binary packages save me a TON of time and effort - the result of which makes my boxes more secure than compiling from source.
Binary packages are a great boon to any sysadmin that manages more than one box..
I admin a few dozen Linux boxes (all slackware
For example, not too long ago I updated Squid (due to a security hole), which was running on 20 or so of my servers.. can you imagine HOW MUCH TIME it would take to compile from source for EACH one (considering they are Pentium 1's)? And that I'd have to have a working dev environment on each one!
Instead, I compile the software on an offline server, and check to make sure it works (another imporant step - Squid changed it's config file between versions, so I had to modify the config file).. then turn it into a package, which gets scp'ed to each of the servers, and installed.
Package management allows me to keep track of each file, so upgrades are painless.. and if one of the servers goes down, I can have a new one up and running in 20 minutes, using the same packages I used to upgrade the other systems.
By using binary packages in this way, my systems are MORE secure, because I'm able to minimize the window of vulnerability, and because I don't have to maintain extra software on the boxes (from a security standpoint, anything you don't need should be removed - on a production server, this would include a compiler.)
Remember - not every binary package is untrusted. The ones you make yourself are as trustworthy as the source you used to create them.
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!"
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."
Loki Setup is now maintained by icculus.org. However, I think that any good package scheme (read: RPM, DEB, Portage, or whatever) is better than this if the administrative tools are good.
http://freshmeat.net/search/?q=installshieldp ://freshmeat.net/search/?q=installer
htt
Everyone and their brother is probably writing an installer (although more people are apparently writing MP3 jukeboxes, Web image galleries, and CMSs. Trust me.) Can't say I'm seeing a "clear winner" though, which is also the case with apt front-ends.
WMBC freeform/independent online radio.
Gentoo provides binary downloads of the larger packages. The stage 3 tarballs (available in multiple flavors to accomodate different processors) provide the basic system, while v1.4rc2 includes the Gentoo Reference Platform (GRP). GRP provides prebuilt X11, GNOME, KDE, Mozilla, and OpenOffice on x86 and PowerPC systems. (It doesn't seem to have been updated for newer Gentoo versions, so it's no doubt a few versions behind now.)
Binary packages are somewhat ignoring the point of Gentoo...yes, they speed along deployment if you have a bunch of machines to roll out, but you could achieve the same effect on a bunch of identical machines by doing one install in the normal manner and then just clone that install into the other machines. The desire of some people for a quick install hasn't been completely ignored.
(For my purposes, I'll usually start with a stage 1 tarball. I built 1.4rc4 inside VMware on a WinXP box at home; even with VMware only letting Linux see one of the two processors in that system, the build ran quickly enough. Once I migrate my stuff off of the existing server config, alfter.us will switch from Linux From Scratch to Gentoo. I've had it running on several servers at work for a while now...it combines the performance and security of Linux From Scratch with most of the ease of setup of a conventional Linux distro.)
20 January 2017: the End of an Error.
Or even half an hour getting Moz-Frirebird
Half an hour? You spoiled, dual 3GHz-running... guy! Seriously, it's more like 4-5 for me.
Why should we choose a binary format when we have Gentoo with which you can download the sources and build your own optimized binaries..
Why should we choose Gentoo when we have the actual sources, with which you can download and build your own optimized binaries?
Is vastly superior to anything in the linux world.
And you all know it too.
Fags.
C'mon, people. This is obviously a joke. It might not be deserving of a 5 (I think it is, but that's not important), but it certainly isn't flamebait.
Hey uh chief, you can have bin pkgs built on one machine the others can install them. Even better use distcc and save some compile time.
Comparing Linux/UNIX Binary Package Formats This is a comparison of the deb, rpm, tgz, slp, and pkg package formats, as used in the Debian, Red Hat, Slackware, and Stampede linux distributions respectively (pkg is the SVr4 package format, used in Solaris). I've had some experience with each of the package formats, both building packages, and later in my work on the Alien package conversion program. I've tried to keep this comparison unbiased, however for the record, I'm a fan of the deb format, and a Debian developer. If you discover any bias or inaccuracy in this comparison, or any important features of a package format I have left out, please mail me so I can correct it. Several people have already done so. I'm also looking for data to fill in the places marked by `?'. This comparison deals only with the package formats, not with the various tools (dpkg, rpm, etc.), that are used to deal with and install the packages. It also does not deal with source packages, only binary packages. Package format comparison table. feature deb rpm tgz slp pkg Security, authentication, and verification signed packages yes[1] yes no no no checksums yes yes no no yes permissions, owners, etc yes yes yes yes yes Usability by standard linux tools recognizable by file yes yes no no yes data unpackable by standard tools yes [3] no [4] yes yes [5] no [6] metadata accessible by standard tools yes no N/A no no [6] creatable by standard tools yes no yes no no Metadata dependencies yes yes no yes yes recommendations yes no no no no suggestions yes no no no no conflicts yes yes no yes yes virtual packages and provides yes yes no ?? no versioned dependencies and conflicts yes yes no ?? yes boolean package relationshipss yes no [8] no no no file dependencies no yes no no no copyright info no [10] yes no yes yes grouping yes yes no no yes priority yes no no yes no Special files config files yes yes no yes yes documentation files no yes no no yes [11] ghost files no yes no no no Package programs binary programs allowed yes no ?? yes no pre-install program yes yes no [12] no yes post-install program yes yes yes yes yes pre-remove program yes yes no [12] no yes post-remove program yes yes yes [12] no yes verify program no yes no no no triggers no yes no no no Scalability no hard-coded limits yes yes [13] yes no no [6] new metadata yes yes [14] N/A no no [6] new section yes no no no no [6] format version data yes yes no yes no [6] What is compared. Security, authentication, and verification. This section deals with ensuring that you know who created the package, and that you can check the package installed on your system to see if the files in it have ben modified since you installed it. signed packages Does the package format contain internal support for a GPG or PGP signature that can be used to verify who created it? checksums Are checksums available for all the files in the package? permissions, owners, etc Is information on the files in the package, their proper permissions, sizes, owners, groups, major and minor number (for devices), etc, available? Usability by standard linux tools. Recognising that it's important sometimes to be able to peer inside packages without using their package managers, this section compares how the various packages can be processed with tools available on any linux system [2]. recognizable by file Is the package format able to be recognized by file? data unpackable by standard tools Can an experienced user, when presented with a package in this format, extract its payload using only tools that will be on any linux system? They can remember a few facts to help them deal with the format, but remembering file offsets and stuff like that is too hard. metadata accessible by standard tools If the package has some sort of metadata (ie, package name, description, version) contained in it, can this data be accessed by standard tools, without too much difficulty? creatable by standard tools Can a package be created using standard tools, without too much difficulty? Metadata. Metadata is my term for the information abo
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?"
Installing from source can take less time and be much easier than installing binary packages. Binary packages depend on one specific set of library versions. For many packages these dependancies are difficult to maintain, without a cascade resulting in the need to upgrade many other packages in your system. If you're building from source, though, you can build the package against whatever versions of the libraries you already have installed...
Days? It takes a month for me to compile and install :)
KDE onto my ancient Sun box. You have a fast box there if it
only takes days.
I should add that month includes qt, kdelibs, kdebase, kdegames, and
kdeutils. The rest of the packages only take a day or so to compile each.
Let's be honest. If you don't follow the correct procedures in the beginning, anything you attempt afterwards will be a band-aid(tm).
Security is a process, not a line item.
Security requires more time be spent and more effort be expended than unsecure practices.
Right up to the point where someone or something happens to your systems.
For example, if it's not a networking application, then I'll usually grep for system calls like connect() or bind() .. a dead giveaway that somebody has tried to slip some kind of a backdoor into the code. If I find something like that, I rm -rf it and forget it. You can also search for calls like gets(), strtok(), fopen(), and other well-known security risks and fix them if you feel like it.
I have two questions. What percentage of the packages you use did you download the source for and grep through? And how many of them did you find trojans in?
If you have not checked your trusted base (kernel, compiler, linker, libraries and whatever tools you use to look at the code), then you can never be completely sure. See Ken Thompson's article, Reflections on Trusting Trust for an excellent explanation of why.
The net will not be what we demand, but what we make it. Build it well.
I'd put Windows just a little ahead of Linux (because of the multiple formats of Linux packages), but OS X (and all Macs) are way out in front in this arena, IMHO.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Because some people run dozens or hundreds of machine with identical configurations, so compiling the same package on every single machine is pointless?
See rsync/rdist
I've been running Gentoo for a few months. I *love* the package manager, except for occasional compile errors (latest problem is with Bash 2.05b-r5).
Anybody know if binary package management would be more stable, but still allow for the somewhat bleeding-edge version releases of Gentoo? I haven't used a binary system in years, so I don't recall what it was like.
Seriously, RPM or .tgz are the only format you need.
Any reasonable arguments for that claim?
You cannot get your binary into the main site without going through a social screening process.
.rpm based installations.
This allows more standardization than amongst the various
Standardization means fewer problems for the rest of the users.
But it means more work for the people developing the packages.
I cant read the article since it seems to be slashdotted, but in my opinion the RPM's and DEB's etc. seem all equally good, the difference comes from how easily you can get them and whatever the package depends on. I wouldn't care if my Debian box would use RPM's, as long as I could still use apt-get to grab them and the dependencies.
See A whole lot of unecessary effort
Mad Software: Rantings on Developing So
George Bush!
Do you have something against negroids?
Cause: The word "apropos" is used in The Matrix: Reloaded
Effect: The word apropos is used on Slashdot.
One of many things that drove me to FreeBSD from Linux was binary packages, specifically RPMs. I built enough stuff from tarballs by hand to know that outside of a few smaller sysutils, many things have a ton of compile-time configurables that aren't modifiable at run-time, such as config file locations, logging options and other sundries, not the least of which might be compiler optimizations, linking options and other things.
Mostly you have no idea what options the binary package builder chose. Some could be stupid, some could be 100% opposite of what you actually want. I always wished there had been a rpm --build-option that would have printed out a summary of the options chosen by the person building the package.
I eventually just took to unpacking SRPMs and building stuff myself, but even that became tedious.
AFIAC it's another bit in FreeBSD ports' favor. I can make extract, check out the build options tweak them and then install the application; a good combination between building it by hand from tarballs (and hoping autoconf or something works right) and accepting a binary that may have been built by someone like me...
"Global warming - A Ridiculous Hollywood Myth!
The binary packages on Gentoo are easy to work with.
Want OpenOffice without waiting 2 years: emerge openoffice-bin
Yeah, it isn't quite the same as compiling from source, but I've never managed to get openoffice compiled from source.
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?
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!
While technically a "binary package format", Gentoo's Portage has a way to create binary tarballs of merged programs. However, this is not meant to be a way to distribute software to random users; instead it's for setups where you have a bunch of similar machines and want to compile once, install many.
When you merge a package, do "emerge -b package". It builds and installs the program like normal, then creates a signed tarball file that you can use to install on other machines. emerge can then take that tbz2 file and treat it as an alternative to the actual compile process.
is to distance ourselfs from the system V filesytem, and have each package installed in it's own dir, this would make things so much easier.
And instead of the old PATH environment variable idea, think of something new, how about a central file (with user modifyable sub-files) that contains a list of all binaries to be called by default.
Or about a package tree in the bash memory, that holds the information which binaries are callable... etc.
There are so much ways to get rid of PATH, and with PATH away, nothing speeks anymore against installing every package in it's very own directory, making administration and package management so much easier...
--
Karma 50, and all I got was this lousy T-Shirt.
Zero Install
"The Zero Install system makes software installation not merely easy, but unnecessary. Users run their applications directly from the Internet from the software author's pages. Caching makes this as fast as running a normal application after the first time, and allows off-line use."
Experimental, but give it a try. See especially the comparison with apt-get and the security model documents.
Huh? No they don't. Most packages don't give a rat's ass where the binary is located. Historically, GCC was one of the few that did, and recent versions have changed that so that you can move the install tree around.
The remaining few packages that care are mostly just suffering from bad design. Fortunately, as you say, they usually pay attention to environment variables telling them where to look.
Here's a better writeup than what I can fit here, at sunfreeware.com. They've been repackaging open source stuff as Solaris-style pkg files for a long time, so they've good experience with these sorts of questions.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
So smart you posted under the wrong story?
I think you mean something different by apropos than I do.
Appropriate, perhaps?
</pedant>
On the commercial side, the most common multiplatform installation tool is InstallAnywhere by Zero G Software. Great tool and certainly has its place along with native binary packages - I've seen tons of enterprise applications that install with InstallAnywhere.
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
I'm surprised nobody mentionned uPM (u as 'micro') so far. I don't know this packaging system very well, but it was discussed on /. a few times IIRC. Seems to be part of uOS, but maybe it can be used on any distro (at least, I see an uPM ebuild on my Gentoo, so I assume this is true) ?
Does anyone have more informations to add about uPM ?
theefer
Considering that Joey Hess is a prominent Debian developer, it is not surprising that Debian looks like the winner.
More seriously, if I recall correctly (I think I saw this a few years ago being mentioned on debian-devel), this comparison was not meant to prove which packaging format is better, it is more like an ongoing self check within Debian on "what we're doing right/what others are doing that we should evaluate". Plain ol' healthy evaluation of your friendly competitors.
And yes, my favorite distro is Debian, after surviving the cultural shock of going through dselect the first time, now I won't accept anyhing less (maybe I should make a t-shirt design "I [debwhirl] dselect" ':)
The header said:"... Another reader sends in this guide to creating Debian packages which seems apropos here. " Apropos is not appropriate in this context. Surely what was meant was: Another reader sends in this guide to creating Debian packages which seems apt here.
Am I the only one who hates it when people use that word all over the place?
Because binary packages of other big distros (Debian, Red Hat) are TESTED. This actually matters to some of us who do proper work, and don't just want the "it compiles so ship it" mentality.
Testing, patching, TESTING. I've got better things to do than compile and test and install and workaround and patch. Hence, I use a proper distro which does real QA.
This is why RPM has file dependencies, though its usage is up to the packager. For example, most RPMs require the file libc.so.6 but it doesn't have to be from the glibc RPM.
Escher was the first MC and Giger invented the HR department.
Todo.
* relocatable packages
* support for arch name in metadata, arch indep packages
* multiple version of the same package can be installed simultaneously (is this really a package format issue?)
Sigh. The guy has an entire section on how well "standard" tools can manipulate these file formats, as if the typical user has any desire to do home surgery on their software.
(Well, why shouldn't he? The typical linux user does want this level of control...)
But there, at the end, in the neglected "ToDo" section, are the real issues. Features that put the user in control of their software instead of the other way around. Is anyone ever going to write a package management system that addresses the needs of the user, instead of the sysadmin?
-pmb
apt is not tied to the deb package format. There is apt for rpm, but the lack of apt-gettable rpm sites is a problem. On the other hand, Mandrake has urpmi which is similar in functionality.
Escher was the first MC and Giger invented the HR department.
It is important to note, that for the PKG format (Solaris, etc) that System V does not define certain functionality, but the system vendor may include it. I know that Solaris does support ghost files, editable config files, virtual packages and boolean dependancies, but the chart doesn't reflect this.
;)
.02
Not that this helps out the Linux community in the slightest...
I still think Apple's (NeXT's) App format is still the best. A complete archive including all features and bits of an app that can be moved around at will.
My
Contrary to popular belief, life is not a bitch. It is far far worse.
Every once in a while, I give Linux a try again to marvel at how far the Linux community has progressed. My latest story partially relates to package managers. Needless to say, I still think that Linux admin is SIGNIFICANTLY harder than it should be.
I tried to update the fixes in RedHat 8. So I FTPd all of the files to my PC. I did this so that I could "recover" my system to the same point without having to re-download 30mb of fixes each time (thanks to the RedHat for not supplying this option or making it obvious of how to save the "fixes" that are downloaded).
I tried to "rpm -i" each of the files I downloaded one by one. Eventually there were three packages left. All packages insisted that they could not be installed because the other package was not.
Now this whole episode took me a matter of hours. Whereas Windows would take me a whole 30 minutes to choose what I did/didn't want to install and then download my fixes.
Now before the ego pumped Linux zealots say "shut up you dumb ass Windows wenie", let me tell you that I have developed software commercially in a defence environment for almost 10 years. I have used more platforms than you can poke a stick at (QNX is still one of my faves). I would really, really love to install Linux but there are so many annoying things... it just so happens that the package management of RedHat is one small pebble in my shoe... Let's not forget pathetic support for ATI cards, my built in audio card (which did not work) and the complete lack of direction for setting up TCP/IP or just about any other device in my system.
The symptoms I experienced (to varying degrees) also applied to Mandrake, SUSE and Debian.
Q: Why doesn't RedHat (or other Linux distro) put up their own web site that "attempts" to hack your Linux box? This would allow people to know how "safe" their Internet connected box was...
Sincerely,
"Dumb ass Anonymous Coward Windows wenie"
My EPM software (http://www.easysw.com/epm/) supports the creation of software packages in multiple formats along with a common "portable" format that works on all systems.
I print, therefore I am.
Ah, this old chestnut. ISTR this comparison of formats was first mentioned on Slashdot a few years back.
.zip format because this is extractable on MS-DOS too; or storing all your images in xpm format because you can view it as a C header file in your text editor (urgh).
I have to take issue with the 'usability by standard Linux tools' columns. RPM _is_ a standard Linux tool and it's easy to install it (or even just rpm2cpio) on systems that don't use it. Systems that don't use RPM would not be interested in RPM binary packages (maybe in source packages, but that's a consideration for only a few users). You might as well advocate making packages in
-- Ed Avis ed@membled.com
I don't know what format it's considered (.run file), but did anyone else install Wolfenstein Enemy Territory on linux? It seriously couldn't have been easier. I executed the file on Mandrake 9.1, a nice little graphic popped up with a logo telling me that I was installing the program, it gave me options of where to install the files to, whether or not to add an entry to the Kicker, etc.
This was the closest thing to a simple Windows installer that I've ever seen on Linux. Absolutely painless, n00bie friendly... exactly what Linux needs to assist in penetrating the desktop.
This file is usually statically-linked, and can be used instead of RPM to install packages in case of emergency.
I was disappointed to see that there was not an included compaison of the .sh (or other script) wrapped packages (usually .tar.gz (.tgz) or .tar.bz2).
Half an hour was a guess. It was less than 3 for sure though. I have XP1700+ with 512mb of ram, so don't get too jealous.
The developer of swaret (update utility for Slackware) and I have been working on resolving library dependencies when a user installs or upgrades tgz packages in Slackware. To make a long story sort, it works great. New release due out 13 July. Info at http://swaret.xbone.be.
I've used many systems, and many package systems.. from old machines where there really was no concept of a package, to debian, with it's superb package management, and everything in between.
The only conclusion I've come to is this: The package format itself isnt' so important.. what matters is the whole system approach to packaging and distribution.
Take Debian. Everyone agrees, I think, that the debian package format, and apt, together make for a great system.. but that's because of the method of package distribution and tracking, not the packaging system itself.. that and the fact that it's fairly universal in the debian world. Several apt repositories make up basically all software available for debian... and it's a lot. SO the overall experience is "Great package management". It's not just about the format, but the people.. people know what's in the standard packages, and can refer back and forth to them, checking for compatability and whatnot. The overall appraoch to package management is what rocks.. not the binary format.
Look at OSX.. they have fink. Fink, if you don't know, is basically apt-get for OSX. Works fine, no problem... except, it puts stuff in it's own folder (/sw) and it doesn't necessairly know about apple stuff already installed.. it only tracks stuff that is in the fink repositories.
In other words.. it's useful, but it doesn't have the feel of a really great package system.. because the system itself isn't based on it.
People say "ports rocks" in bsd land... but why? Becasue it's superior? No.. just because it's a big collection of useful stuff that handles dependencies well. The actual package management system is extremely basic. But the system is more or less based on it, so it works very, very well.
Redhat.. is kind of a mess. Is it because rpm sucks? Heck no.. it's just because, well, the overall approach wasn't right.
OSX.. (yeah okay I'm a mac fiend now.. I admit it.). What package management? Apps tend to be one single file, which is a package containing all the bits and pieces. No real package management system to see what's installed or not.. and who needs it.. you can just go to the Apps folder and toss stuff in the trash to get rid of it. The system was designed to work that way. so it works really well. You don't say "Gee I wish the system tracked apps" because it's so very simple to get rid of them, and to ferret out any pieces they may have left behind, which is rare..
So overall... the complexity of the package management isn't as important as everyone sticking together on how things are going to be installed and removed. If everything works the same way, it doesn't really matter how sophisticated it is.
He states that rpm is not unpackable by standard tools.
Can an experienced user, when presented with a package in this format, extract its payload using only tools that will be on any linux system? They can remember a few facts to help them deal with the format, but remembering file offsets and stuff like that is too hard.
First problem I have is with the "any linux system" Ummmm I've a Linksys router running Linux that can't do jack with any of these. Next an RPM is actually a cpio archive rpm2cpio is actually just a tool to shortcut what is doable with cpio. This applies as well to all of the "standard tools" statements. I also would like to point out that standard depends on which standard you use. Posix, LSB etc. In that rpm is a standard of LSB but not of Posix.
His statement that binary programs are not allowed.
Must these programs be scripts, or can compiled binaries be used as well?
This is very, unclear. Can I execute a binary from within rpm. The answer is yes. I do it all the time. Can RPM be made directly from binaries (skiping all of the build etc.) Yes it can. Can I embed the binary in the RPM and not have it ever get installed... no. But I can run it then remove it before RPM finishes.
Suggestions ... he states that RPM doesn't have them.
... but it's up to the packager to use the tool. Second the author needed to get a little deeper into rpm's queryformat (info here) He would have found much of what he needed.
A suggestion says a package may sometimes work better if another package is installed. The user can just be informed of this as a FYI
This is really the fault of the packager not of the product. There are two areas for comments which can give you this kind of data
Statement that RPM can't do Boolean Relationships.
This means that a package can depend, conflict, etc on a package AND (another package OR a third package). Any boolean expression must be representable, no matter how complex.
RPM does have the conflicts and the depends paramaters that can be set. Once set you can't install a without b and c, plus removing y and x.
HOWEVER he is very right about the boolean "or" being missing... I've been championing this one for a while (I've talked with some of the developers.) but it seems it hasn't up till now been high enough on the horizon to have someone take a shot at it. (Sorry but it's beyond my ken to work on this personally) So I will keep politely advocating this until it does break the plane of need.
New Section
.. On a system that uses this product how do you do X" will yeild a completely different answer.
Sorry but this stament is just too nebulous. It's been coping with the unforseen for years. Just as debian has. That's why it get's upgraded. That's in fact a lot of the reason for the new version coming out now. To make the format more modular. and easier to mutate as times change.
All and all the article seems well done. However I'd say the chances are pretty strong that the author is a Debian fan. My personal recommendations would be. One lose the subjective nature of a number of statements. Next, when doing research be careful how you ask a question. Often times asking "Can this product do X" will yeild a no. But if you ask
I'd give this article all in all a 6 on a 1 to 10 scale for research. a 3 for new info. and a 7 for layout and style.
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
Security isn't the issue. Neither source nor binary is more secure over the other from the standpoint of trojans.
.tgz file that you can download, check the md5sum, tar xzvf, ./configure, make, and make install is because that's the de-facto standard. Some people like other mechanisms for some packages, but most people expect to be able to install stuff that way. For me, as soon as I encounter an .rpm or a .deb package, it's a hassle.
.tgz files that I can do a ./configure; make; make install on.
The reason that every decent package out there is available in a
There are other downsides to trying to invent "proprietary" methods of distribution. First, there won't be a migration to a single standard. Some people just don't like distribution method X. So, there will be an increase in the number of different distribution methods, and that has an effect on package creators, package consumers, and the popularity and usage patterns of packages depending on which distribution method they pick.
Maybe we're already too far down that road to turn back, which is okay I guess... just as long as I can find all the parts I need in
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.
It's interesting to see how similar the .deb system is to the FreeBSD Ports collection, if you look beyond the details.
They didn't review FreeBSD's, one of the best there is. What a fucking waste of time.
... is that this article was writtin 5 years ago. I don't believe Gentoo really existed back then :).
I'm somewhat amazed that there used to be a standard package format for SysVr4, which I think many Linux distros model after. Why is it historically so that every distro seems to need its own package format, instead of adapting towards the standard?
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
I'm one of the developers of the Autopackage project, and we have bumbed into the relocateability problem since Autopackage allows user (non-root installs).
/proc/self/exe. However, this only works for applications, not for libraries. We still haven't found a solution for libraries, so for now we are using a "semi-hack" solution called libprefixdb.
/etc/ld.so.conf! I don't think that's a good thing.
In Linux (dunno about other Unices), there is one way to tell where the application's binary is: by dereferencing the symlink
Using a shell script is another solution (since shell scripts can find out their own location), but too only works for applications.
Personally I don't understand what's the big deal about AppFolders. How do you want to handle dependancies? I don't think that shipping all dependancies in the app folder is a good and efficient solution. That'll make us no better than Windows apps which also ship all their dependancies.
And second, why should the user even care about where an app is installed? They launch the app using icons and menus, and that's the only thing they should have to know! Letting them know where the app is installed to is exposing implementation details. Users shouldn't have to know about that (unless they're programmers or something).
And installing each app in it's own folder would require 200+ entires in your PATH variable and
You can have my Gentoo when you pry it from my cold dead hands, apt-boy!!
Might want to check out the ESP Package Manager. It seems to be able to generate output for multiple 'single package systems'. I just stumbled onto it while looking for more info on packing options. Haven't used it but it does make for a good/polished presentation...If the software is half as good...:-)
-l
First off, the entire "metadata" section is FUBAR. tgz isn't a package management system; it is a packaging system. Something like portage is needed on top of it; comparing tgz to rpm is like comparing yaml to jabber. Therefore, entire sections in this "comparison" should be marked N/A, not "no".
What this with "documentation file specially marked?" tar tzf | grep. Duh.
Oh, and tgz files are indeed recognized by file.
* Are you gay?
_ | | | | | | | | | | | |
* Are you a nigger?
* Are you a GAY NIGGER?
If you answered "Yes" to any of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
Why not sign up now? It's quick and easy, only 2 simple steps!
First, you have to obtain a copy of "GAY NIGGERS FROM OUTER SPACE THE MOVIE" and watch it.
Second, you need to join the official GNAA irc channel #GNAA on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!
If you are having trouble locating #GNAA, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.isprime.com as one of the EFNet servers.
If you have mod points and would like to support GNAA, please moderate this post up.
P.S. To keep this post on-topic, the GNAA prefers PS2 over XBox, because of the availability of Grand Theft Auto: Vice City, which happens to contain gay niggers, and crazy straight crackers that you can kill!
-A Proudly Gay Nigger
Gay Nigger Association Of America
_________________________________________________
|_______________________________________._a,_____
|________a_._______a_______aj#0s_____aWY!400.____
|___ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#____
|__j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,__
|__"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01__
|_________"#,___*@`__-N#____`___-!^______________
|__________#1__________?_________________________
|__________j1____________________________________
|_____a,___jk_GAY_NIGGER_ASSOCIATION_OF_AMERICA_ |
|_____!4yaa#l____________________________________
|_______-"!^_____________________________________
|________________________________________________
|________________________________________________
...considered a gross misfeature? Count me in.