Petreley on apt-get vs. RPM 240
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.
take the time to *learn* RPM (Score:1)
Oh yeah, and let's not forget the obligatory "rpm is open source, so if you don't like it fix it", etc.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re:Apt-get rocks? (Score:1)
Yes, but (a) Windows software installs mess with the Registry, and gladly throw files everywhere, without the system knowing anything about who put them there, when, or what they do. They're just kinda there. (b) Windows tends to crash. A lot. (Yes, some people will tell me "but MY windows install never crashes!" - Sure, for different values of "crash" - but if you never leave your machine up for more than 8 hours at a time, you may be lucky enough to never see it.) All the changing of files, tweaking the registry, really messes things up.
Windows and MacOS may be easier for the "I have no clue and money to burn" set, and for them, well, that's just lovely for them. Those people expect a computer to be an appliance, a simple machine, when it's far from that. I can't do anything for those who don't understand that.
Remember, software is the most complex artificial construct we've ever created - people expect perfection from it, without understanding the complexity of it.
_____
Re:Works great - unless (Score:1)
_____
Re:Can I do this under apt? (Score:1)
Re:Why ca't you use it in RH? (Score:1)
Re:Apt-get rocks? (Score:1)
I hate to say it, but...damn, you must have done something wrong.
Re:Can I do this under apt? (Score:1)
Note quite "all packages out there in packageland", but all packages in your local Red Hat install:
[dougk@chief dougk]$ rpm -ql rpmdb-redhat
/usr/lib/rpmdb/i386-redhat-linux/redhat
/usr/lib/rpmdb/i386-redhat-linux/redhat/Basenames
/usr/lib/rpmdb/i386-redhat-linux/redhat/Conflictna me
/usr/lib/rpmdb/i386-redhat-linux/redhat/Group
/usr/lib/rpmdb/i386-redhat-linux/redhat/Name
/usr/lib/rpmdb/i386-redhat-linux/redhat/Packages
/usr/lib/rpmdb/i386-redhat-linux/redhat/Providenam e
/usr/lib/rpmdb/i386-redhat-linux/redhat/Requirenam e
/usr/lib/rpmdb/i386-redhat-linux/redhat/Triggernam e
/usr/lib/rpmdb/i386-redhat-linux/redhat -q --whatprovides libesd.so
[dougk@chief dougk]$ rpm --dbpath
vorbis-1.0beta3.20010206-2
Re:Can I do this under apt? (Score:1)
So, assuming the RPM that contained the file is part of the db (everything on the main disc's, but not including powertools), you can do something like:
rpm --dbpath -qf /path/tofile
and find out that package "foo" contains it.
My only beef with debian package management. (Score:1)
On the other hand, it's strength is also a weakness, if you want to stay on the bleeding edge of source trees (as opposed to bleeding-edge packages). I do not understand the underlying package format, no do I have the time to learn (at least, not right now). While there is a hack available to add pusedo-packages to the dpkg database (to allow you to provide the dependencies for those packages that you are actually compiling from source); it is clumsy to use, and requires full knowledge of how to maintain debain packages (I would really prefer to maintain a simple /etc/* text file containing a
list of manually supplied package dependencies, or
something like that).
The place where this got really annoying for me is with Perl. Perl is a core part of any Linux system - there are many non-perl packages that depend on it one way or another. Perl has it's own package system in CPAN that is totally incompatible with any Linux package management, and is much more fine-grained (usually Linux distros manage Perl as one or two packages that contain only core functionality; not the hundreds of interesting, useful and/or exotic CPAN offerings available). And Debian has been ultra-conservative in terms of up-revving Perl versions - also a real annoyance when I was using it. (Yes, I am using Red Hat now, but I would be happy to jump ship again.)
Even better would be a package management gateway/hook which would allow linking these two package management systems together in some sort of relationship, but that's probably too far-out to ever become reality.
I guess the other alternative would be to say "Screw this facist package management shit!" and install Slackware instead. :)
--
Why RPM and other Redhat stuff will wither away (Score:1)
Debian is build on software contributors and the principle of free sharing of knowledge not on a business model.
Re:Addressing problems w. inconsistant modem dialu (Score:1)
debian good for users, but rpm good for developers (Score:1)
Sure, the needs of users can be said to outweigh those of the developers, but at some point benefits to developers communicate directly to users, especially in a homegrown system like Linux.
Re:Binary patches would be nice (Score:1)
It would be a great advantage, and I don't think that it would take too much time to implement. Someone might have already done that. I should check it.
apt-get vs rpm is not even a valid issue (Score:2)
about?
apt-get is just a frontend to a packet manager, created for debian and nowadays it has been ported to rpm environment.
I for example have an apt-get repository of rpm files I use to keep my linuxes up to date. Altought redhat 6.2 depencies were not good enough and I've had to recompile some packages with patched rpm.
Btw. There was an article about this in freshmeat.
My distro rocks and yours is dumb (Score:2)
Re:Can I do this under apt? (Score:2)
At uni, so not a debian box atm
but yes. But you can't have file by file dependancies as you can with rpm.
Re:BSD ports vs. Debian apt-get (Score:2)
apt-cache does the equivalent of searching and interogating the ports tree (make search KEY whatever) and apt-get does the rest
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 source bit needs work IMO, although I'm not an expert - I merely had a bit of a play because I was bored
Downsides: no CVS - if a package gets a 5 line patch you need a whole new binary or source package for it.
Hard to modify makefiles exactly - tends to be rather hardcoded to do what it likes anyway.
This was a rather cursory view. And I know that the first issue at least has been raised before on debian mailing lists.
- Andrew
How do linux-distros make money ?? (Score:2)
But debian has catches as a base (Score:2)
What has caused me to throw up my hands and give up on debian more than once is that its behavior is subject to change on the whim of an individual developer: all of a sudden, a package will change the way it behaves. For example, a year or two ago, fvwm2 suddenly decided that any default besides manual placement of windows was wrong, and routine upgrades changed this behavior. (That it overwrote the existing sytstem config file without making a backup or asking permission is a bug, not a showstopper).
There are also the occasional sudden decisions that files belong somewehre else.
I'm not complaining about Debian as a linux distribution (or as a X/BSD/Perl/MIT/AT&T/GNU/linux distribution
The problem is that it *does* change fundamental behavior, and that it sometimes does this suddenly. It lacks the very "singleness" that is needed for a standard.
hawk
Merging of rpm and apt-get would be pretty silly (Score:2)
What would be useful would be to build a version of apt-get that could use RPM as the packaging tool instead of dpkg. Which is something people are working on...
Re:Can I do this under apt? (Score:2)
The first problem you describe essentially requires that you have an RPM or dpkg database that is prepopulated with all the information from all packages out there in "packageland."
It might be a reasonable thing to try to extract such information from some place like RPMFind.net [rpmfind.net]; but the essence of the matter is that you need to have all the packages available for query, which is not likely to be the case on your PC at home if you're using APT to get at packages remotely.
As for the second problem, of "recursiveness," there's both a touch of inherent danger, and an answer with APT.
The parallel aspect of this resolves most of the problems you suggest.
In effect, the problem is that RPM could use a "helper" rather like APT in order to cleanly satisfy dependancies for a clean install of software.
It's not that RPM is "broken;" it's that it really needs that "soul mate/life partner." :-)
Re:Binary patches would be nice (Score:2)
HOWEVER, if GLIBC (and other programs) had a basic exoskeleton which did nothing more than pull in loadable modules, then you can start talking some serious improvements on the current system.
On a completely different note, Netscape is running a survey on whether Judge Penfield treated Microsoft unfairly. Slashdotting polls leads to excessive bias, so here's a large keg of virtual beer to all who ensure the results are, ummm, accurate. :)
Re:Its about time... (Score:2)
Uh.. (Score:2)
Re:Dependencies (Score:2)
Modify /bin/install to insert entries into the RPM database for the individual files that are installed. Then rpm doesn't have to root through your filesystem trying to guess where you installed openssl. It would be even better if autoconf could grab a little info from the .spec file that came with the package, and pass the basic package info to /bin/install, that way doing the equivalent of a 'rpm --rebuild ; rpm -U ' when you do a make install. I sometimes find that I have to hack the source, or pass extra options to ./configure to get something to compile. Then using rpm to create a binary package from a hacked source tree is a real pain. (rpm only wants to create packages from .tar.gz or .src.rpm, and if they don't compile, it just sucks).
--Bob
Re:Dependencies (Score:2)
> I don't mind having to go root around for my rpm updates, in fact I prefer this so these benefits for apt-get aren't of great concern
> to me.
Sourceforge lists a couple of utilities to handle this problem: pkgwrite & checkinstall.
I haven't had a chance to thoroughly examine how well they work, or which is better. But you know this advice is prolly worth exactly what you paid for it . . .
Geoff
Re:Apt-get rocks? (Score:2)
Absolutely, but I've spent half an hour updating RPM's just to get an ICQ client to work on my Linux box before. Double click an
---
Re:Apt-get rocks? (Score:2)
I just ran into the problem of the ICQ RPM needing another RPM which needed four other RPM's which needed 12 more RPM's...
You wind up needing to replace half your OS to run an application, which ticks me off.
I'm not a moron, I could learn the intricacies of the operating system, but I don't want to. I want it to "just work". I guess I'm old fashioned that way...
---
apt-get -- rpm? (Score:2)
I don't want a lot, I just want it all!
Flame away, I have a hose!
Re:The _REAL_ difference (Score:2)
RPM-the-library has the capability to check for specific files, but real world RPM packages never do. Thus, if you ever bypass the RPM mechanism you're screwed. If appfoo-1.6 needs libfoo-2.1, then why the hell can't appfoo-1.6-i386.rpm check for the existance of the libfoo.so.2.1 file? Why does it demand the existance of libfoo-2.1-3-i386.rpm, which in turn demands packages for libfoo-patch-6.9b, libsnafu-0.0.4-pre, gnomesnafu-0.0.4-pre2, kdespuge-3.0.1b9, and on and on and on. Before you know it, you have the entirety of GNOME, KDE, and XFree86-4.0.2-patch9 just to run a stupid ncurses program.
Sorry, I'm ranting. I'll go take my pill now...
Re:Why not standardize on ports/package tree? (Score:2)
Re:Can I do this under apt? (Score:2)
On a different note, the main thing that's broken in rpm (imo) is its lack of recursiveness. I recently installed the updates to RH7. I had a bunch of rpms and did 'for i in *rpm; do rpm -Fvh $i; done;' and of course about a dozen failed because foobar-1.0.0-1.rpm needed foobar-devel-1.0.0-1.rpm which hadn't been installed yet. Re-running the command takes care of this simple (but annoying) problem, but more insidious is the situation where it won't update something because another package depends on it, but you are also updating the other package, so the dependency doesn't matter. You end up installing a bunch of stuff by hand with --force --nodeps. Am I being an idiot? Is there a better way or is rpm as broken as it seems?
Re:The _REAL_ difference (Score:2)
Eh, so has every distro.
The main difficulty with porting apt-get to RPM (and in fact, the main difficulty with any automated system for RPM) is that there are no standards about how to make your rpms. You just do it whatever way you wnat.
So what you really say is that it's bad packaging. I would call that the packager's fault, and not blame rpm.
RedHat themselves don't conform to the LSB filesystem standard, which doesn't help.
This is where it gets really wrong. To start with, LSB is not a filesystem standard (LSB is not even completed yet!), FHS is (and is completed).
And yes, Red Hat 7 plays by the rules of the FHS very nicely.
IMHO, any packaging system must have complete and strict dependencies, and policies on these so that a package is not valid unless it's correct and pretty damned complete, and it must comply with the LSB as much as practicable.
I sense some confusion. A package shouldn't confirm to a filesystem standard. That's just plain illogical. You'll end up with hard-coded paths that are wrong on many systems. Instead, you should use rpm macros when packaging an rpm and specifying paths, macros that will make things go where they should on any rpm system. That makes stuff exactly as portable as you want.
Good packagers use macros, bad ones don't.
Debian does this, no RPM distros do.
Maybe because you're asking for the wrong thing?
Hence, Debian is easier to maintain.
Given the above, I don't understand this argument.
The only problem I see is people who cannot understand the difference between a problem with bad rpm packaging and a potential problem with rpm.
Re:The _REAL_ difference (Score:2)
I don't agree with you on the point of ease-of-use. But even if we let that aside, you think it's Debians packaging policies that make Debian packages shine. I don't understand your point, in my experience rpms done by Red Hat are also excellently packaged, maybe even better.
If the same policies were strictly applied to rpms (as you claim SuSE does), then they would be as good (except that apt-get and dpkg rock :).
They are strictly applied. I still sense some confusion here. You have to be able to distinguish between the two different subjects:
Each distribution has their own packaging policy. Debian has their own. Red Hat has their own. SuSE has their own. And so on. Just because Red Hat and SuSE share the package technology doesn't mean they share package policies. On the contrary.
A particular package technology does not enforce a particular packaging policy. You can use the same technology but have different views on how packages should be named, for example. Neither should a technology enforce a policy; policies are usually only a "political" decision and have not much to do with technology.
As for the technology, dpkg may have some interesting aspects. But as for Debians packaging policy, I don't think they are as good as you make them out to be. Debian naming OpenSSH packages "ssh" to make users confused what ssh is installed is just one example.
Still, the dominance of RedHat and the incompatibility between the RPM based distros doesn't bode well for rpm in my books.
So you're blaming differences in distributions on the package system used? Please explain, because I fail to understand the reasoning.
Netscape Poll (Score:2)
"Was Microsoft the victim of a Biased trial?"
Gee... before or after the purjured themselves in front of the Judge? Repeatedly?
Current results:
Yes = 65%
No = 35%
(I voted no, which of course means they got a fair trial and should be split apart into lots of itty bitty MSs that can be auctioned on E-bay for $5 a pop
Re:Apt-get rocks? (Score:2)
Er, that is possible?
I'm not particularly impressed with that as a complaint. I prefer the `so go get a clue' answer infinitely more than "oooh sorry, I'll make it all so much easier for you". Grrrr!
"We need something"...
We already have rpm, RPM, and apt-get and dpkg. At least with apt, if you read the article you'd have read the bit about "stay with stable". What he didn't do was to name `testing' per se, but that's a reasonable idea anyway.
What RPM needs is the ability to grok package pools/repositories. Apt doesn't need anything, that I can see.
~Tim
--
Re:Apt-get rocks? (Score:2)
Real software takes a while to install. The trouble is with people who expect otherwise.
~Tim
--
Re:Absurd (Score:2)
apt-get install foobar3
apt-get remove frotz12-dev
What could make it easier? I've also never had apt, dpkg or dselect crash on me or behave in strange fashion. The same is true of RPM. What sort of instability are we talking about here?
As for Debian become a standard, I hope the auther is kidding! Debian may not be the worst distrobution, but RedHat trumps it in every catagory...featurs, stability and price.
Features are somewhat in the eye of the beholder, but I'll happily admit that Red Hat's hardware detection and install are much better than anything in Debian. Progeny [progeny.com] have a Debian-based dist that solves that one nicely. Other than that, what features do you feel are present in Red Hat that aren't adequately available in Debian? In terms of stability, both are based on the same kernel and use the same XFree. I've had pure Debian systems running for over a year without crashing. Again, what stability issues do you feel exist with Debian? Stability is certainly not something that I'd bae a choice of Linux distribution on, mainly because they're all pretty much identical in this regard. As for price - Debian is free. Completely and utterly. You can find people who will sell you official CDs for the price of duplication, and you'll get the complete distribution. How much cheaper do you want it?
Re:MONEY IS THE REASON (Score:2)
Have you ever tried to get soemthing from RedHat's ftp server?
Yes (Score:2)
However, you can also do it the other way around, like you asked. dpkg -S <filename> will tell you, given a file, what package it belongs to.
--
apt works with debian... only! (Score:2)
Let me give you an example. I have added Ximian Gnome's sources to my
SOOOO, whenever Debian updates to a higher version than Ximian, apt will tell me that it needs to de-install sawfish, which will in turn de-install a number of my Ximian packages that depend on sawfish. Of course, I don't really want that.
Currently, the only way to solve this is to tell apt to "hold" the Ximian versions of sawfish and sawfish-gnome. This is somewhat annoying and a direct result of name space collision. A better solution, IMNSHO, is to have some sort of global package naming policies. So that in the above problem Ximian would name their deb's "sawfish-ximian" and "sawfish-gnome-ximian" (for example) and each package would provide "sawfish" or "sawfish-gnome". Then when the dependancies were trying to be met, I could choose which set of packages I wanted to meet those dependancies.
All of that being said, I'll still take apt/dpkg over rpmfind/rpm anyday.
Re:Its better than apt-get or rpm (Score:2)
Why not standardize on ports/package tree? (Score:2)
Its a solid system, ALL of the BSD's use it in some form or another, it allows source installs, it saves the install info as TEXT, its been tested and proven by years of experience.
It seems to me that ports is really the best system. I noticed that gentoo linux [gentoo.org] is using it now, although slightly modified.
I would *love* to see one package standard for all of the bsd's AND all the distro's of linux!
Openpackages all the way baby! [openpackages.org]
You can. Petreley, and most posters, are clueless (Score:2)
* APT does not compete with RPM.
* Deb competes with RPM
* APT is packaging system independent
* APT was *designed to be* packaging system independent
* APT works with RPM
* Connectiva uses APT
* Mandrake 8 (currently in beta) uses apt
* Connectiva also has a n excellent set of packaging guidelines, which document things like package granularity, etc (current situation - libmng might be in libmng package or qt2 packages).
* AFAIK (from talking to Debian people and using it for a little while) Deb lacks package signing, and transaction support.
Can I do this under apt? (Score:2)
One of the things that is nice about RPM is being able to say "rpm -qf filename" and having RPM tell you what package filename belongs to. Unlike certain other alleged operating systems *cough*Windows*cough* when you find some unknown 100 MB file on your system, you can ask "Who's fault is this?" of RPM.
(obviously, if the file in question wasn't installed by RPM, it won't be in the database. Nothing can solve this...)
Can you do this with apt?
Why ca't you use it in RH? (Score:2)
I'm a newbie
</disclaimer>
If apt-get is so good, why can't you use it in RPM based distros? (RH, Mandrake)
BTW, is there any
Both RPM and APT are poorly designed.Bundles Rock. (Score:2)
Comparing apples to oranges... (Score:2)
Apt-get is a utility used for installing and updating .deb packages. It currently has it's largest amount of support for the debian package management system, but there are also beta versions for .rpm and other package managers as well.
While apt-get is definitely a bonus for the debian distribution, because it makes things tremendously easier, it should be considered an application. I think it would be *great* if all linux distributions used apt. It is not necessarily a bad thing for apt to use different package managers underneath though!
--
Twivel
Re:Fighting the wrong battle (Score:2)
They can still do this with the iso's. Listen, they are NOT going to make money any more by selling the CD's unless:
1. There is SIGNIFICANT non-free software with the box. If a box had Word Perfect or some other non-GPL software, it would be a better buy then the iso.
2. They close the source....which they CAN'T do!
Also, I have noticed that up2date or the redhat network will allow you to download packages even if you are not a member. Debian, being a non-profit entity, will never charge access fees for apt. Therefore, it's still better. Nick brings up a EXCELLENT point about apt in that when Stormix shut their servers down, he can just point it at Debian's servers and still be ok. If Red Hat goes belly up, RPM will probably die, unless someone else picks it up. Also, RPM's database can too easily get corrupted by forcing installs which can be and usually is necessary, plus most bigger projects like KDE doesn't post a order of installation(at least they didn't last I checked), so you almost have to force the install to get everything going unless you know the order. Red Carpet by the Ximian folks is great and will allow a conduit for them to make money if they ever release some closed source stuff, or they can get money from a closed developer to allow them to put a channel in red carpet to let people buy their software thru it. and Red Carpet is INFINTELY better then Eazel's stuff (Eazel is limited to what's on Eazel's servers now, plus server reliability is lacking!).
I also might add that it's EASY to upgrade a kernel with APT and dpkg. Just grab the kernel-package and the kernel source deb you want, build the kernel deb with a one line command using make-kpkg. This builds a deb including the kernel and kernel modules. When you use dpkg to install it, it will even run lilo for you. (I think! I only did it once, but all I remembered was that it was MUCH easier!). One time I did a RPM kernel upgrade and RPM didn't edit lilo.conf or run lilo (was I supposed to? Did up2date remind me? no!, but Red Carpet didn't either though...) and I was unable to boot. Sure, I could have fixed it, but after futzing with it for too long I said screw it it takes less time to re-install, and this was a new install so I didn't loose anything....isn't this why we are trying to AVOID Windows??? Debian has it right.
Wrong! (Score:2)
Re:Apt-get rocks? (Score:2)
I have too... its definitly possible to blow your system up doing that. Unstable is where packages get initally uploaded to. Its the development distribution - and you have no buisness syncing against it unless you are willing to have your system blow up and need manual fixing.
(actually - Ive never had my system "blow up" from it, but I have had a package or two break and make a few things blow up - its almost never that difficult to fix, if you know how)
In short, ther eis no quality control on unstable. Its where packages go so that people can use and test them. They havn't been formally tested (like the stuff in "stable"), sometimes stuff blows up in there.
-Steve
Perl dependancy (Score:2)
Still kicks RPM's ass though
BSD ports vs. Debian apt-get (Score:2)
I would like to see an objective review of these two "packaging" formats. Any comments?
Re:Why bother? (Score:2)
And given that dial-up users in general will be home users, security updates are doubly important for them because it may be the only way they harden their boxes.
Re:3 hour download is no big deal (Score:2)
I doubt that downloading binary diffs of the stuff that's changed would amount to a tenth of the download time.
Re:Not the same thing (Score:2)
I love apt-get. I was using RH distros up until a year ago. RPMFIND is a nice way to locate packages, but I found that going out and grabbing packages, downloading them, finding out missing deps and then repeating the process to be a chore.
Then I started trying out debian for a machine I wanted to build for a samba file server in my house. Once I was able to grok dpkg + dselect + apt, I was thoroughly impressed and comfortable in switching my main box to Debian.
Of course YMMV and choice is a good thing. But I agree that apt and rpm are apples and oranges.
---
Re:MONEY IS THE REASON (Score:2)
Redhat doesn't have apt because otherwise people would upgrade to the latest version simply by downloading all the upgrades. Instead they buy the CDs.
What stops people downloading floppy install image and upgrading over ftp to stay up to date?
"bandwidth" (Score:2)
*sigh*
Kiddie: "I've got LOTS of bandwith"
Clued: "Oh, really? What, rom 20 KHz to 200 MHz?"
ever notice... (Score:2)
Ah, hell... just use an Amiga or an SGI.
Re:The _REAL_ difference (Score:2)
rr
Re:The _REAL_ difference (Score:2)
rr
Re:Apt-get works with RPM (Score:2)
rr
Re:The _REAL_ difference (Score:2)
- The debian policy, in my experience, produces better, more consistent packages.
- Due to this consistency, apt-get and so on are made possible. I haven't tried the various tricks that are used to get apt-get working with rpm, but given my previous experience, I don't see them as being likely to work. I could be wrong here.
ie, the policy enables the technology to work. I assure you that I understand the difference between the two, but I am not convinced that you understand the link... make sense?rr
Re:up2date (Score:2)
Re:I love Nick Petreley (Score:2)
Just because your so called experience contradicts Nick's doesn't make you the grand poobah of IT either. While I think that the truth lies somewhere in between, this malady DOES exist and will continue to do so as long as companies continue to hire MBA's with nothing more than a good pedigree to be CIO/CTO. Furthermore, the biggest problem with your post is your reliance on your own personal experiences. I'm sorry, but your experience in IT is insanely insignificant compared to Nick's. Sure, I don't always agree with him, but he has a tremendous amount of knowledge in the world of IT and an even greater amount of integrity.
Cheers,
Re:Binary patches would be nice (Score:2)
Binary patches would work best if the compiled code was predictable and modular. Unfortunately, it depends so much on what CFLAGS the guy compiling it used that day, the phase of the moon, and the exact pattern on their t-shirt, that it would prove complicated.
I'm not sure I follow this. If you're going to provide binary packages, why not binary patches? Sure, there are hundreds of different possible settings when compiling an app, but if you're going to provide binary packages, you've still got to choose one of them.
What I'd like to see is a package patching system. For example, you give it foo_1.2-1.deb, apply the patch, and out comes foo_1.2-3.deb.
I'm sure it can't be as simple as a binary diff between the two files because there's compression happening, but some multi-stage process of unpacking, patching, and repacking would probably work.
And then, if it were integrated into APT, it could maybe combine an FTP site with a local CD to reduce download times considerably.
--
apples vs. apts (Score:2)
What I understand apt-get to do is 'intuitively' reading the deps portion of a debian package and dloading binaries from the registered 'sources' list (what is that file called..?) and installing them for you. It is an 'automagical' frontend to retrieving and installing debian pkgs.
I think this apt vs rpm argument is a little off base - again im not intimately aware of any package system, this is just what ive gleaned about them over time - is that rpm isnt comparable to 'apt' at all. RPM is a package standard - with its own format and features - but 'apt' is an application to retrieve packages (debian ones). What is necessary is a 'apt' application to retrieve 'rpm' packages. My understanding is not deep enough to argue the ad/dis vantages of either package format... I would suggest neither is the author of the article.
Our Brazilian friends at Connectiva are working on an APT 'port to RPM'. [www.http]
Slashdot has a discussion about this the apt-rpm project here [slashdot.org]
What i have described above may be all completely wrong - but this is how I understand it. Please correct me if this is so.
Re:Apt-get rocks? (Score:2)
I really have to disagree with you there. First off, even for very intelligent and motivated individuals it can take a long time to "get a clue". Second, compare installation procedures with apt and rpm with windows (for example, using install shield or some such). It's really no comparison, the windows installer is much more straightforward and simpler to use. GNU/Linux still suffers from the "disease" of being designed for the technologically elite and the already extremely clue inclined. I don't fault gnu/linux for this, it's a great OS and it has numerous great applications. But in this modern push to transform gnu/linux into the next great generic workstation / desktop OS it is an incredibly disadvantage and these problems have still not been fully addressed and ameliorated, though the situation certainly is improving.
I shouldn't have to have a trancendental understanding of every nook and cranny of my system to install a simple piece of software. Similarly, I should not be forced to know the exact specifications for the "black box" fuel injection control electronics on my car if all I want to do is drive it someplace or change a tire or the oil or open the trunk or the moon roof. Linux is a tool, not a toy. It should be optimized for being used as a tool and not optimized for being used as some sort of technological play ground. Some of us need to do serious work and we don't want to have to play around with your cumbersome systems created because you like to answer arcane configuration questions and you have nothing better to do than spend all day installing one piece of software.
Re:I love Nick Petreley (Score:2)
Problem with packages (Score:2)
All package systems suffer from the same thing though. It's an all or nothing system. Is there any system which lets source installation, and then recognises what you have installed in terms of packages, i.e. I can install glibc from source, so apt doesnt know it's there, but then run apt-refresh and then it will know.
Re:GLIBC is too bloated to begin with. (Score:2)
GNU needs to break it up, if you ask me
Let's make a couple of quick substitutions to the above...
s/GLIBC/Microsoft/g
s/GNU/The Department of Justice/g
Those who can, do. Those who can't, get their MCSE.
MONEY IS THE REASON (Score:2)
Redhat and other RPM distros, could have serious dependency headaches in order to go from one version release to another. The main catch is, this forces people to buy a newer version to stay on the forefront of linux. If I could buy Redhat 6.0 and just 'apt-get distupgrade' all the way up to 7.0 and to future releases, I wouldn't have to buy any more releases from Redhat EVER AGAIN! Unless Redhat makes an apt repository and charges a subscription service, their older customers are not going to need to buy newer releases.
Conclusion: Debian is a non-proft organization. Debian has an excellent packaging system. A debian user can type in a command and upgrade the entire distro to a newer version. Debian has no fiscal incentive to push point releases as we all know. This is because stability and robustness are of utmost importance to debianites. How long did it take from the 2.1 release to 2.2 again?
Redhat is a for-profit company. Redhat has a decent packaging system. Installing a package may be troublesome if you have to find a package that contains the file that the program you're trying to install depends on. It is easier for most users to either buy/download a newer version to stay current. Thus, redhat sells more copies because people can't buy just one distro and upgrade ad infinitum. In other words, money may be the reason.
What do you guys think?
apples and oranges (Score:2)
"apt-get" is a tool for network updating of distributions. Its equivalent in the "rpm" world are "rpmfind", "urpmi", and a bunch of others.
In my experience, "apt-get" works quite well while "rpmfind" and "urpmi" don't. The reason for that isn't some technical deficiency of "rpm", it's one of user community: there isn't the same dedicated group of volunteers keeping network repositories for "rpm" up-to-date and available. rpmfind.net is a great effort, but it's a one-man operation.
So, should we all switch to Debian packages? I don't think so. I think the dependency management in "rpm" packages is better and more robust than that in "dpkg", and I believe "rpm" packages encourage third party contributions (outside a single monolithic development organization like Debian) more.
If there is demand, maybe people can volunteer and bring systems like "urpmi" or "rpmfind" up to speed. Several commercial vendors are also trying to fill the gap.
Of course, a more fundamental question to me is whether continuous updating is even desirable. In most corporate environments, stability is probably more important than getting the latest bug fixes (yes, even getting the latest security bug fixes).
Re:I love Nick Petreley (Score:2)
These two sentences are only marginally related. Yes, upgrades require a lot of prep work. That's why their frequency is so damn annoying. As for the frequency itself: You've never, ever heard an IT person say "maybe you need to upgrade" in response to a problem request? You've never seen a user ask for a feature that can't be supplied by the current version? You've never found incompatibilities between new software and your non-upgraded "legacy" software? You are a lucky, lucky troll^H^H^H^H^H man.
--
Non-meta-modded "Overrated" mods are killing Slashdot
A clear "no" is in order (Score:3)
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.
Re:Isn't this really a flame? (Score:3)
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.
Re:apples vs. apts (Score:3)
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).
--
APT is already used on (at least one) RPM distro (Score:3)
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
Re:Not the same thing (Score:3)
-----
"You owe me a case of beer. Sucka'."
I love Nick Petreley (Score:3)
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
Re:BSD ports vs. Debian apt-get (Score:3)
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.
Isn't this really a flame? (Score:3)
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.
Re:Absurd (Score:3)
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.
Re:Apt-get (Score:3)
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..
up2date (Score:3)
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.
Re:Can I do this under apt? (Score:3)
Debian puts in *effort* (not just apt-getting) (Score:3)
If all RPMs were standardised and sanitized too, there'd be no contest between DEBs and RPMs.
RPM solves deps too (urpmi/urpme/apt-get...) (Score:3)
# 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... :-/
Not absurd (was Re: Absurd) (Score:3)
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."
Dependencies (Score:4)
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 ...
Not the same thing (Score:4)
Re:BSD ports vs. Debian apt-get (Score:4)
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 :-)
Binary patches would be nice (Score:5)
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.
The _REAL_ difference (Score:5)
rr