Reply With QuoteWell from my experience, debs work and rpm's don't. I haven't had much experience with rpm's but I have had almost a year with debs and they've never failed. (The programs in them might though.)
Are there any big differences in the two? From my understanding there pratically the same thing. I'd like to know which one is better. I'm talking about the packages and not that fact that you usually get debian packages through the wonderful apt-get
Well from my experience, debs work and rpm's don't. I haven't had much experience with rpm's but I have had almost a year with debs and they've never failed. (The programs in them might though.)
debs have some more precise information for dependencies because debs are intended to be used with apt, which will do dependency resolution and actually download any dependencies a program needs (e.g. Konqueror needs KDE libraries to run, which, in turn, KDE needs Qt to run, so apt will first install the Qt libraries, then the KDE libraries, and finally Konqueror.)
However, Connectiva has ported apt to use rpms, but it's not clean. There are things that debs have in themselves inherently that make things like simplified updating easy. Rpms do not make use of any configuration scripts when they are installed, whereas debs do. Rpms do not stop and restart daemons (this is related to the previous point) and debs do. And since debs have more precision in specifying their dependencies, an rpm dependency database would be much larger since apt would have to fill in the gaps.
ROFL...
Ok, RPM's DO have indepth dependency information, and order information, and with tools like up2date (which is free for one PC at a time from Red Hat Network) it can auto download/install dependencies if you wish it to.
You can also dump a crapload of rpm's into a directory, give an rpm -Uvh * and it will sort them out, and install them in the order needed to solve the dependencies.
IMHO, there isn't much different between RPM and DEB. Just the systems that use them, and the users that swear by them....
After all our talk, I found a good article on Freshmeat that discusses this: http://freshmeat.net/articles/view/192/
You'll notice that there are, actually, a few major difference between the two.
Also, read some of the references, one of the links has a good table showing all the difference between dpkg and rpm, and another discusses some of the issues that were raised when they were developing apt for rpm and in particular, how it would be necessary to change the rpm format to get apt to work with it nicely.
I think one of the main differences is that if you try to install an rpm that has missing dependencies, rpm will barf and tell you what files you need to install first (but it won't tell you where to get them or what package they are in). apt-get will tell you what packages you need to install, and ask you if you want to install them.Are there any big differences in the two?
That's why there's an rpmfind.net, but no debfind.net. debs are better
ohhh so debs are only better because of apt. One of the first things that bugged me when I switched to linux is the packages. I was confused for a while. I thought windows was so much better because you could download and double click something to open it. Now I find rpms and debian packages are so much better.
From a security standpoint, the apt-get methodology is weak for a few reasons. First, it has no central authority. If you point apt-get at Corel, Storm Linux, etc. it will freely allow you to overwrite packages, key rings, etc. Second, the ownership of packages in the debian apt-get system is to individuals, and no one individual claims responsibility for those packages. Its a case of "who watches the watchers." Anyone maintaining a package for pat-get could slip in a trojan horse, and the user would happily apt-get it, probably without their knowledge as it automagically meets dependencies. It wasn't that long ago that someone released a trojan of util-linux, so the threat exists.
Red Hat, since it is a commercial distro, provides a central authority for its packages, and does extensive quality assurance testing on packages released in their distributions/updates. The apt-get system does not require QA on its packages, leaving it up to the individual maintainer to test his packages, which often does not occur, and causes systems that apt-get updates on a cronjob to be broken.
Also, it is important to remember that while apt-get automatically meets dependencies, this means that the system is likely installing packages that the user is unaware of, in order to install the package that the user was requesting. Ignorance about ones own installed system packages is a security flaw in itself.
Well first of all, apt-get only has those security flaws if you choose for it to. By default, your sources.list file only contains Debian servers and they're commented out. Users can't add all kinds of different servers without knowingly doing so. Also, it does display the extra packages it's installing before you confirm it. If the user doesn't bother to read them, then that's his problem.
Note that apt-get is not the only way to install deb packages. In fact, you'll have fun trying to apt-get a package that's saved on your hard drive. Apt-get is just a front-end for dpkg. Dpkg is much like rpm except that I've had better luck with it. So Debian users can do it pretty much however they want. I don't see any reason why not to have your computer do all the work for you though. Try apt-get and you'll see what all the fuss is about.
RPMs dependencies can get tricky at times. However I have a feeling that most people have never read through the RPM man pages. Like KP said, up2date works wonderfully, as well as the old -Uvh which I have been swearng by for some time. And, not to mention, every now and then you just need to throw in an old --nodeps, when you know all your dependencies have been covered and rpm is just plain lying to you.
Posting Permissions
Bookmarks