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)
Why don't you just ask what everyone's favourite distro is?
Apt-get, no emerge, no make world, ARRRGH!
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
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.
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.
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.
[
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
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
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
If your paranoid enough not to trust the RPM Builders, the checksums, the download process, etc, then download the src.rpm; unpack the contents, and do your vodoo tricks. Then run rpmbuild to build your own damned binary package. I've done it (Ok, I'm a RHCE) and its cake.
Basically, this isn't a reason to dis binary packages unless your paranoia is well into the tinfoil hat level.
You are in a maze of twisted little posts, all alike.
One of the main reasons I enjoy DEB binary packages which also do not have any of the bad issues you mention is this:
.deb from that, not just to install on that machine (Personally I like the fact i can remove it with a package manager) but i can also install that binary package I made myself on my slower systems that dont have a compiler installed.
I'll download the source and compile it on my nice fast zippy P4 2.6ghz machine, then build a
My three router computers are all p133 or p166 machines. No way am I compiling anything there. Routers also dont need gcc installed.
I run my own private apt repository for this (Its just apache and some config files in text format, and one more line in my apt sources file.)
This way I can tell whichever machines to apt-get it, and later I can apt-get remove it as well.
I also dont have a huge server farm, I just have 8 machines at home for different purposes. Below the P4 mentioned above, my next fastest system is a p2 450. The others get way slower below that (p2 200 and the like, or worse.)
I also dont want a compiler on any system but my development system. The machines in my DMZ dont need compilers, as if they do happen to get rooted, that's one less tool for them to use aginst me.
Open source is also about choice. Please let us have ours, even if you have made your own.
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!
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.
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.
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.
Every time I've bought a car I bring a socket wrench set with me and tear apart the engine right there on the dealership floor. If I didn't how could I know that Al Queda hasn't set me up to be a pawn!?! Not checking your equipment like this is tantamount to supporting terrorists.
You have got to be kidding. Do you think everyone who uses Linux has the time to do that for every package they install? When I installed Debian, I wanted X. I typed 'apt-get install x-window-system'. The following download and install of all the required packages took about a half hour (over dsl). Your way would have taken me about 2 hours to get all the right packages, and another couple days to compile them from source (after of course checking for security vulnerabilities and fixing them myself).
Not everyone who uses a computer is a programmer. Not everyone who is a programmer is paranoid enough to think that a binary package from RedHat contains a secret connect() to send out their passwd files. Not everyone who IS a programmer, and who IS that paranoid, has the time to audit the code of every package they install.
For these people, binary packages are quite convenient and useful.
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."
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.
Have you ever heard of signed binary packages ?
Mandrake RPMs are security-signed, and if they don't have a valid Mandrake GPG signature, you get prompted as to whether you really want to install them. I'm sure most other distributions which use binary packages do the same.
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?"
Each of these does what InstallShield et al. do: install a program, keep track of how & where it was installed, and give the user the the ability to uninstall it.
I've had problems with un-installing things on my Windows XP box at work: too many software makers try to get around it, and there's no way to figure out where things were put. At least with Unix, I can do a find(1) before installing, then after, do a diff(1) and figure things out from there if I don't trust the developer.
What's not simple by installing (say) Apache with an `apt-get apache`? Under FreeBSD it's `cd /usr/ports/www/apache2; make install clean`. Out of all the systems I (personally) think that FreeBSD's and Debian's are the best (prefer FreeBSD in general as an OS). I haven't used Gentoo though.
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.
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.
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....The only way you can be completely sure is to read the source.
You haven't read the entire source of the GNU/Linux system you're running, so you have no business telling us that we ought to do it!
Why am I so confident you haven't read the source? Because it's not possible. Even a relatively basic Linux install will correspond to over 2GB of source code. That would be about 800,000 pages of a typical book (2500 to 2800 characters per page). Source code is typically much less dense in terms of characters per page, so it would be millions of pages. It would take you several years to read it, by which time the bits you'd read first would be long obsolete.
Cause: The word "apropos" is used in The Matrix: Reloaded
Effect: The word apropos is used on Slashdot.
suggestions yes no no no no conflicts yes yes no yes yes
Ahh, I understand...
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'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!
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.
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.
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
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.
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.
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.
.figure out the best way to install your packages.
Why didn't you just drop them all in a directory and execute rpm -Uvh * instead of manually installing one at a time? That let the package manager do what it does best . .
As far as the 30 minutes on windows deal, on my Debian box I type apt-get update; apt-get upgrade and walk away. On my Gentoo box I type emerge sync; emerge -u world and walk away. Mandrake has urpmi that does the same thing, Connectiva has apt for rpm. If you would have looked, Redhat8 has an automatic updater that will do it for you. Shit, even Slackware has an automatic updater in the works.
Get your information straight before you bitch. Just because you can't figure it out doesn't mean it doesn't have that capability.
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.
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.