Slashdot Mirror
Petreley on apt-get vs. RPM
cagrin wrote to us with a recent Nick Petreley feature on LinuxWorld. In this feature, he writes about one of my most favorite parts about Linux: Debian and apt-get. He's advocating that Debian become the standard for Linux, as RPM doesn't cut the mustard compared to apt-get. Now, granted, I've been able to blow up my machine before with reckless apt-get dist-upgrade -- but that's running unstable, and my own fault. Apt-get rocks.
apt's purpose is quite directed, namely to track the associations of inter-package dependancies.
It leaves the task of tracking specific files to a completely separate piece of software called dpkg. Or, if you use the "beta" version of apt-get, the database of files installed would be maintained by RPM.
So, supposing you want to know what files are associated with the Netscape package titled netscape-communicator, you might use the commands:
dpkg -L netscape-communicator
or
rpm -ql netscape-communicator
depending on what packaging tool you prefer to use. Note that neither of those commands involve apt in any way, shape, or form.
If you're not part of the solution, you're part of the precipitate.
First of all, Nick is currently employed by Caldera (which isn't Debian based), so it isn't necessarily a question of him asking to standardize on what he has chosen. It's actually a pretty brave stance.
But Nick isn't really arguing that for the universal acceptance of Debian Linux. What Nick is essentially doing is arguing for a "binary" Linux Standard Base. This has been a fairly constant theme since before the LSB was even born. He contends that unless there is an installable distribution against which commercial software developers can build and test their software there will continue to be problems for Linux distributors and Linuxers in general.
Debian Linux provides a perfect base on which to standardize. All of it's software is freely redistributable, and it is technically an excellent distribution. More importantly, it isn't a commercial institution itself, and therefore it makes sense as a "common ground."
The other choice that makes sense (IMHO) is RedHat. RedHat Linux is also useable in it's freely redistributable form (there are no proprietary pieces that are absolutely necessary), and it already has quite a bit of market share. In fact, to my mind Nick's article is simply pointing out to the non-RedHat distributors their one and only chance of checking RedHat from becoming the standard. The other commercial Linux distributors are not very likely to want RedHat Linux accepted as the binary standard for Linux (they already have enough problems with it being the de-facto binary standard). If all of the non-RedHat distributions threw their weight behind Debian as the binary standard then RedHat would maybe be force to follow their lead.
Otherwise the rest of the Linux distributions are probably all in for a very long trip off a very short pier.
From what I understand about ports (im not a BSDer) is that the port 'application' will retrieve a maintained list of makefiles/configure scripts from a central repository - and duplicate that organized collection onto your BSD box.
Close. There is no port "application", it's just a directory that's maintained by the FreeBSD developers that contains the meta-info for the package (description, manifest, dependencies, patches, etc) for each port, broken into categories like net, x11, editors, www, and so on. This directory is synchronized with cvsup, which is sort of a cross between cvs and rsync. Same thing you keep the base distribution source up to date with (why the OS itself can't be broken into ports, I don't know. Want to use the right tool for the job I guess). All the dependency management is done with make, there's no "port" application that checks for dependencies. So the ports application would be 'make' -- it's the sort of thing make was made for, and it does it swimmingly.
One major difference between ports and apt sources is that the location of the port is on a per-port basis. Often there's a copy mirrored on freebsd.org (or whatever your bsd distribution home is), but the port will try to download the source from its original location first, before trying mirrors (and if all else fails, you can download the binary package manually).
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
I totally agree with the folks that previously stated clearly that you can't compare apt with rpm - on debian, apt sits on top of dpkg (or something like that, I am really not a Debian user), and dpkg is the component/architecture that maybe could be compared with RPM.
But the important point here is that apt can sit on top of RPM too, and there is at least one full RPM-based distro already including apt as the core of its package management duties. It's called Conectiva Linux (www.conectiva.com, in english). Have a quick glance at this excerpt from their PR (http://en.conectiva.com/linux/):
"The biggest and most remarkable advantage of Conectiva Linux 6.0 is the Advanced Package Tool, also known as APT. Previously APT was only available for .deb packages but was recently enhanced to support .rpm packages too. Conectiva 6.0 is the first rpm-based distribution with fully integrated apt-get support. This new tool makes it easier to keep the platform up-to-date and secure, since it can automate the update and installation of all .rpm packages. APT, when used as an (automatic) upgrading tool, can detect the availability of new versions of .rpm packages, and take care of download and installation. In corporations, APT has a very crucial importance in terms of security, because with it, the system administrators can facilitate automatic corrections and upgrades in a very fast and easy way, getting around the manual work of updating every machine in the network with, for example, the security update. Conectiva employee Alfredo Kojima, who is also the author of WindowMaker, has enhanced APT to support RPM packages."
I thought you'd like to know that...
--
Augusto Campos - www.linux.trix.net
-----
"You owe me a case of beer. Sucka'."
Consider this beautiful piece:
Corporate IT is currently plagued by a type of obsessive-compulsive disorder known as DUH, or Dementia Upgradia Habitua. It manifests itself through the irrational assumption that the only way a company can maintain a competitive edge in productivity is to upgrade to the latest and greatest hardware and software. Since hardware and software are continually changing (change is almost always considered to be progress, of course), DUH compels corporate IT to remain in a continual state of upgrade.
Hrm. I've been working in IT for 4 years now, and I've done a lot of consulting. In all that time I have never seen a shop where upgrades were constant or even frequent. I've worked in about 20 shops now, and in each, major software upgrades had to be a) justified to upper management, b) undergo extensive testing, c) be completely documented and d) have a backout plan. Now maybe I've been lucky, but it seems more reasonable to assume that Nick is somewhere off in cloud-cuckoo land.
But being wrong is not a good reason to flame someone. This is why I don't flame newbies, they don't know any better, and they're open about it. Nick Petreley on the other hand writes like he's god's gift to technology. Not only does he invent various maladies afflicting corporate IT, but he goes on to question the intelligence of these fictitious chronic upgraders. How can you not love him for this?
Now admittedly, this is not Nick's best work. I much prefer his Linux Doesn't Do Windows And Neither Should You era drivel. Nevertheless, it's pretty good and helps establish Nick as the premier jackass among Linux advocates.
Sure RMS can be a bit embarassing at times, and the ESR, Bruce Perens feud is always good for laughs, but at the end of the day, Nick Petreley is the king. He's like Bowie J. Poag but with much more visibility.
As a Microsoft shareholder, I'd like to congratulate Nick on his achievements. Keep up the good work.
--Shoeboy
apt-get can also build source - apt-get -b source will build it - however this isn't done like the ports tree - it won't pick up all the dependancies in the same way that the binary packages will, or at least not that I've seen while playing with building apache.
The latest version of apt supports the build-depends field in packages, which fixes this problem.
Downsides: no CVS - if a package gets a 5 line patch you need a whole new binary or source package for it.
That depends. If it's an upstream change, yes. If the package maintainer makes an alteration, you keep the same upstream tarball and just download the new version of the Debian alterations.
Why I appreciate apt-get as an excellent update tool two things strike me as odd with this article:
1. Everyone already know this
2. "Lets all standardise around MY choice".
He may very well be right about the superiority of apt-get, but this seems like an obvious flame to me.
Besides, apt-get != deb. apt-get is an excellent tool that was created for Debian packages, but it IS being ported to RPM.
>>> Installation is easier under apt-get, perhaps, but what happens when you want to uninstall? Apt-get's uninstall capabilities are horrible.
:: will remove package and everything that depends on it.
:: will remove only package and nothing else.
Uhm, I don't think you know what you're talking about.
apt-get remove <packagename>
dpkg -r <packagename>
apt-get is all about dependency resolution and package retreival negotiation, and dpkg is all about what packages have to go through when they are being built, installed, or removed.
From what I gather, rpm tries to roll both of these into one program which can be rather annoying when you're used to the soundness of debian's package design. It's no wonder Corel saw the light of easy, straight-forward package maintainance.
>>> one missing feature from apt-get, is the rpm -qa | grep somestring
You redhat strays astonish me.
here's how you do that in debian: dpkg -l |grep <something>
Gee whiz. I bet you've never even heard of the program "dpkg".. my god!!! is all humanity hopeless?!?? oh woe is me..
I'm all for competition. I just can't wait for the ruckus to start "aptget rawks, up2date is a come lately wannabe", or "up2date is the best cause it like has more options and stuff" and of course the ever present "f*ck you, I compile my sh*t from source cause I'm a true haxor". Let the wars begin and may the best app win.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
Yes with dpkg -L package, most if not all and more of the query options for rpm are in dpkg as well.
*shrug*
The reason why apt-get is so nice is not just the downloading and installing, it's the fact that Debian packages are built by (mostly) experienced maintainers who are trained to follow Debian's one true standard, which they have to follow to get packages into debian.org. I would say that probably, most Debian users just have *.debian.org in their sources, and therefore only recieve standardized and sanitized packages.
If all RPMs were standardised and sanitized too, there'd be no contest between DEBs and RPMs.
Does my bum look big in this?
# urpme kdesupport
To satisfy dependencies, the following packages are going to be removed (80 MB):
kdelibs-sound-2.0-5mdk kdebase-2.0-7mdk
kdegraphics-2.0-4mdk koffice-2.0-2mdk
kdesupport-2.0-1mdk kdeadmin-2.0-2mdk
kdetoys-2.0-1mdk kdeaddutils-2.0-3mdk
kdelibs-2.0-5mdk kdemultimedia-2.0-4mdk
kdeutils-2.0-3mdk kdenetwork-2.0-1mdk
Is it ok? (Y/n)
Really my main concern with RPM is that you have to be root to install a package - I mean: why should you be root to install a prog in your own directory just as you install a tarball... I think it's an issue for people who don't have root access on their machine (most students for example...) so they cannot install anything in their accoun but a tarball, which is not as easy as RPM. Ok they can also use rpm2cpio, but it is not very elegant way... :-/
I've been using SuSE Linux for a while, and the reason that I'm switching to Debian is that I'm sick and tired of dealing with libraries, differing versions of RPM, and many different RPM packages wanting to place stuff in different places. I like the fact that 'apt-get install ' will check my dependencies, FIX my dependencies, and run configuration tools (if set up for such) for the packages installed. Even if the RPM library database is 'better', it still doesn't FIX the dependencies for me, and I don't feel like downloading 15 or more files, figuring out the install order, figuring out the dependencies for THESE files, etc, when I can get a utility that will generally do it all in one swoul foop. Yes, I'm lazy, but if you look at the history of these POSIX compliant OSes, that's generally been the consensus (i.e. two letter long commands).
Another gripe I have (since I'm doing such a wonderful job already) is that the differing versions of the RPM tool are really starting to get annoying. I've got a SuSE 7.0 based box, and it seems like most of the RPMs pointed out by rpmfind.net just don't work, being too new of a version. I've tried to retrieve newer versions of RPM, but some moron has rpm'ed them with THAT VERSION OF RPM, and I can't extract it! grrrrr
</rant>
"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
If rpm could be configured to look around, in the standard places, for a particular library it would greatly simplify my life as a sysadmin. For example, openssl is stuffed into /usr/local/ssl. In recent RH rpm updates ssl is required but since I hadn't installed the openssl rpm it wouldn't install those packages until I take the time to --force it or --nodeps or whatever is necessary to get it to go.
Many packages I install manually because of the complexity of getting many installs working properly. The Apache-php-mod_ssl-openssl-imapd combination is one good example. I like to be able to update all of these packages as soon as possible if a serious problem occurs with any one of them. This is also the reason that I don't bother with kernel rpm updates since I normally am 2 minor versions ahead of redhat anyway.
These dependancies should be extended from the rpm level to library level. If an rpm for a given library is not found then rpm should go looking for the default location of the library itself before coming back with an error. I'm not even sure that it should be an error, perhaps a very strongly worded WARNING would be better, or at least a configuration to do this by default. Hmmm, I wonder if I'm missing something ...
:wq
Surely apt-get is an app that sits on top of dpkg - rpm is not an app for getting updates so you can't compare the two. You should be comparing apt-get with red carpet or something equivalent for a true comparison...
--- If something doesn't feel right, you're probably not feeling the right thing.
AFAIK,
The conventional wisdom is that BSD ports and Debian apt are the two most powerful and versatile upgrading systems around. Apt downloads packages from central Debian servers and takes care of every detail, including dependencies, in installing them on your system. A port downloads the source from wherever it is (the makefile usually specifies up to 50+ servers to try, depending on the port), builds it if necessary, and installs it, taking care of every detail, including dependencies (run and build) and complile-time options.
To editorialize, either one is a good way to run a clean, stress-free system. Note that although it would be just as easy to download a precompiled package from a central server and install it on BSD (pkg commands with/without make install), the "cultural" emphasis in the BSD world (correct me if I'm wrong) is to compile from source. Obviously this is a more resource-intensive model (and one ends up with a number of versions of make), but BSDers like it (after all, it puts the "source" in open source). And there are those compile-time options.
Although, there is room for improvement in both apt and ports, both seem to have the right idea as to what constitutes a good way to upgrade a system. Thus both should continue to be excellent options.
Note: for downloading/tracking a large source tree, CVSup actually is perfect, with no room for improvement :-)
"Frederick, is God dead?" --Sojourner Truth
A recent security recent hole in Mandrake required I download about 40Mb of GLIBC RPMs! Why??? The fix itself was probably a few changed lines in the source code so why not distribute it as a binary patch? The alternative for modem users is a 3 hour download, something only masochists will bother doing.
rr
Quidquid latine dictum sit, altum videtur.