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.
Oh yeah, and let's not forget the obligatory "rpm is open source, so if you don't like it fix it", etc.
in debian:
apt-get update;
apt-cache search foobar
this almost *ALWAYS* finds it. you'll want to install foobar-dev to get the headers.
Um... It's a client. It's told where to go through a file in /etc/apt/sources.list -- of course, if you would have read the article, you would have known that.
:)
So, unless someone's cracked your nameserver, you should be fine.
Of course if someone has cracked your nameserver, maybe worrying about where apt-get is pulling from is not your big problem.
I'm just curious as to why Dial-Up users even bother running daemons at all...
like gnome-apt?
apt and rpm aren't the same, been said already.
regardless though, try the system before actually making the assumption that dpkg+apt and the debian binary tree is not something to standardize on.
once you realize how DISTURBINGLY easy dependency handling is, you won't come back.
i mean, yes, some like to configure the source for their programs, (BSD comes to mind) but for libraries, things like binutils, etc, this is nice.
I think that most of us are really missing hte point here when it comes to the debian system, apt, the 'base', and what it really means.
:) and still gathers a sizable userbase because of it's more BSD-like setup. I don't think it's going anywhere soon.
Basically read debian-devel for a couple of days.
After you manage to wade through the 1000 or so messages you'll undoubtedly get, you'll realize that each and every day, there are a disgusting amount of people that are inspecting, patching, and checking on the latest whathaveyou for your packages.
Find a bug? Submit it -- if it's a core package, expect a response back in MINUTES. I found a bug in debconf, reported the bug to submit@bugs.debian.org, some correspondence with Joey Hess (the maintainer), about an hour later he was packaging a bugfix which I downloaded the next morning (the apt mirrors sync twice a day, IIRC).
Similar (repeated) fixes with the lilo package have come like this as well.
If you want to get at the changelogs for apt-getted packages, install the package 'apt-listchanges', which will show you what's going on before it's downloaded... Although, I think this is only in the unstable distribution.
Basically the system is slick and will only get better. Ironically, I was making this comment earlier today that in the end, Debian and Slackware will end up being the only dists left..
Before anyone trolls, note that Slack was one of the first major dists (after SLS and Ygg, RIP
It's really no comparison, the windows installer is much more straightforward and simpler to use.
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.
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
"[T]the list"? What list would that be - you mean the list of supported cards? Well, if you happen to have a NIC not on _that_ list, well, woe is you. And *DHCP* support? I do believe either dhcpcd or pump is installed as part of base!
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
This is a bit sad; at one point, the Cooker was apt-enabled.
Stating on Slashdot that I like cheese since 1997.
Stating on Slashdot that I like cheese since 1997.
I hate to say it, but...damn, you must have done something wrong.
Stating on Slashdot that I like cheese since 1997.
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
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.
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. :)
--
An esoteric scratched itch:
Homeworld Map Maker Tool
Very simple: Backed by an venture capital funded corporations with an insane oxymoronic business model. As soon as the money runs out the steam on RPM will fizzle away and we all can finally unite behind Debian.
Debian is build on software contributors and the principle of free sharing of knowledge not on a business model.
Yes, apt-get can resume partial files, does download everything to a holding area before installing and with apt-zip you can do the sneakernet thing by copying files to Zip (or other removable media) at work, and taking them home to upgrade you machine (for example).
Debian: GNU/Linux done the Linux way
My understanding is that the debian packaging system is much more difficult and inelgant from a package developer's standpoint. In fact, there is no way to extract or reconstruct the original set of sources and patches that went into building the piece of software. This makes it much more difficult to update packages. Say you have a package for XFree86 version 4.0.1 that has four or five patches from here and there on the internet applied. Now you download version 4.0.2, and you want to package it up. With RPM you can retrieve the original patches from the source RPM and examine them to see which ones still apply cleanly, which ones are no longer necessary, and which need to be modified. With the Debian system all the patches have been smashed together into a single patch, you can't tell which is which or where anything came from!
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.
A nice addition to the packaging systems used today, is to add rsync support as a downloading method. Thus, if I already have an older package, and assuming that the packages do not change a lot between releases, all I hvae do download is the binafy diffs of the PACKAGES.
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.
As has been said previous, RPM's lack of an apt-get style tool kills its usefulness. RPM could be the best package management system in the universe, but as long as I have to hunt for a bazillion RPM to upgrade my system, and get maddening "depends on /bin/sh" errors forcing me to repeat the process, well--it'd be less headache to just compile and install the source!
Package managers are supposed to make installs and upgrades convenient. If RPM is more of a hassle than downloading and compiling source, why use it?
--
#19845
Mandrake's beta distribution (Cooker) is also using apt-get and various people have set up their own private apt-get archives for Red Hat.
This means that "apt-get vs rpm" is plain stupid, since they work together just fine. It should be ".deb vs .rpm", but those two are so similar that it doesn't make much sense to fight over ;)
That's not rigt. Read the apt design docs, and look here afterwards. (42? coincidence? I don't think so)
Don't sweat not knowing the options, I've been using Debian for 3 years and didn't know about apt-get remove until I read some of the threads in here. Debian is really only using one package "program", dpkg. Apt and dselect are just wrappers for dpkg that fetch/manage packages. Dselect is the older manager, apt is the new kid on the block.
This is why I like linux. We have choices. Now for some people Debian is the choice other use RedHat. while others use Suse. The point of this article is just introduce you to another choice. Now thier are people who prefer to use RedHat for whatever reason they can it is thier choice they can change it when ever they choose to to. That is why I like linux
nstallation is easier under apt-get, perhaps, but what happens when you want to uninstall? Apt-get's uninstall capabilities are horrible.
Could you tell us what exactly you missing?
Szo
Red Leader Standing By!
You can, take a look at this fresmeat article!
Szo
Red Leader Standing By!
Well, 'rm' has the ability to wipe your system, too. If you are newbie, don't touch the default sources.list, it's that simple. If you feel like doing things you don't understand, that's your call...
Szo
Red Leader Standing By!
The idea is that RPM itself would install a modified /bin/install, that has the same interface as the "standard" one(s). That way programs don't have to know or care whether they're on an rpm system or not, but RPM systems would automagically get entries in their databases whenever a 'make install' uses /bin/install.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
Nick forgot to mention apt-cache which would have helped him quite a bit there on looking for proper package names...
I have to say that that is probably one of the best and most well thought out articles of Nick's that I've ever read. I've never used Debian, but I have to agree with the case he puts 100%. apt-get does sound like the answer to a great many of my upgrade headaches
Well done Nick, keep pushing that message!
Macka
A masochist is someone who starts the download and sits there watching it, without realizing that Linux can run more than one program at once.
I regularly do apt-get upgrade over my modem. If the download is going to take a while, I fire up my compiler and get something done.
It's really not a problem for me. Even with regular downloads, I use wget -c so I don't even need to get a huge file all at once. I've done this with full CD-ROM images, over a period of days.
If tits were wings it'd be flying around.
Well I think that dselect rules and you should all remove apt-get and dpkg from your system.
It _can_.
:)
If you want a seperate copy of the rpmdb, copy it into your directory.
Then, of course, you would need relocatable packages( which can, and do, exist). After that, you specify which rpm database to use. of course, you would need to be root to install certain files into certain directories, but DUH!
The real problem lies in too many package maintainers building as root and having their build install stuff during the build.
My Suburban burns less gasoline than your Prius.
apt-get/dpkg does not use file dependancies. You won't get error messages complaining about a file missing like you would from RPM. Instead it relies on package versions. If you compile something your self and don't make it into a package, apt-get/dpkg has no way of knowing about the files or what version they are. If you installed it in /usr/local then you shouldn't have to worry since debian policy dictates that no packages in the distro can put files in /usr/local unless they are compiled on the local system. Since the default path statement lists /usr/local/bin first you'll be using the binaries you compilied instead of those that came in the package. As for kernels, there is a neat little util called 'make-kpkg' that helps you build kernel packages to install so you system knows all about what kernels you have installed. It also makes removing an old kernel a breese and warns you when you try to do something dangerous (like install new kernel modules over the ones you are using).
Add to all this the fact that debian/unstable usually has the latest version packaged and backporting is soon going to be very simple (Something called Build-Dependancies are being worked in so that the system will automatically download and install the packages needed for building the package -- think BSD/ports) and you will find it easy to keep what ever packages you want up to date.
Of course some of these things (like dropping file dependancies and reserving /usr/local for local binaries) would have to be incorporated into any system that wanted to get the full benifit of apt. Thats why I use debian. Makes keeping my server up to date and keeping up with security fixes a breeze.
So do you really think that Red Hat designed 'rpm' for the purpose of making money? That's going a bit far, don't you think? From my point of view (user support) I prefer do have a clear delineation between distribution versions on a system. I *like* the idea of knowing if one of my systems, or someone else's system, is RH 5.2 or RH 7.0. I then know pretty well what I'm dealing with, and what the issues are. I don't have to wonder about software rot (which doesn't just happen on Windows) on a system that has been upgraded ad nauseum since Linus' first child. No sensible support system would accept to support such systems. Even though in principle you should be able to upgrade systems seamlessly, in practice people screw things up, and a clean install of a recent distribution version from time to time is not a bad idea.
For all you people who have been asking how to find a certain package using apt, apt-cache search foo will search the available package descriptions for "foo".
If you would have read the article closely you would have noticed that he modified his apt.sources to point to the unstable version of Debian (Woody).
It has not been as well tested for bugs and conflicts as the stable version. So you see, it technically was his own fault.
(I've slightly messed up a debian installation by grabbing unstable too. I managed to work it out though. I've never on the hand messed up anything simply by updating from the stable distribution.)
That's not an rpm. That's a src.rpm. Two completely different beasts.
A Government Is a Body of People, Usually Notably Ungoverned
Thanks for your answer....
Yes, I usually use RPMFind to solve the first problem, so at least that's a reasonable solution as long as I have a net connection. Seems like you should be able to write a script to scan through a set of rpms looking for a particular file. But I can't figure out how to list the contents of an rpm unless it's already installed.
As to the second, perhaps recursive is the wrong word to describe it....global might be better. A way to look at the whole bunch of packages I'm updating and take care of dependencies automagically. A friend of mine set up a Debian system recently and he showed me how apt works. I had heard all sorts of good things about it, but this was the first time I saw it in action. I was stunned. dselect could use some work, but apt is just awesome.
Also, if the other response to my question is correct (use rpm -Fvh *rpm instead of the for loop) then rpm already takes care of this situation, but I was too ignorant to realize it (not that the documentation is any help).
Admit nothing, deny everything and make counter-accusations.
If I understand this correctly, you already have to have the package installed for this to work. Otherwise you get "No package provides libesd.so". What I'm after is a way to find out what rpm a given file is in so that I can install it to satisfy ./configure.
Admit nothing, deny everything and make counter-accusations.
I'll be dipped.....
:)
If this works, I'm going to kick myself. Classic case of doing it the hard way when the easy way is actually better. I can't wait to do another upgrade to try it out.
Thanks for the response, and also for not answering the "Am I just an idiot?" question.
Admit nothing, deny everything and make counter-accusations.
> and did 'for i in *rpm; do rpm -Fvh $i; done;'
Try rpm -Fvh *rpm .
That will upgrade all of them in the proper order at the same time.
Christopher McCrory "The guy that keeps the servers running" chrismcc@gmail.com http://www.pricegrabber.com
>I nuked my server with rpm -Uvh --nodep --force with libc6 and the 2.2 kernel. Oops. Maybe I should play around with apt-get... or is mv / /dev/null a better solution for me.
If you had to use --force and --nodeps, you did something wrong.
To update glibc and the kernel this would be the procedure:
download the rpms
read some release notes.
rpm -Uvh glibc-common-... glibc-devel-... glibc-2...i686.rpm
(if you are on a PII or up)
For the kernel itself: NEVER do a --freshen or --upgrade
rpm -Fvh kernel-utils.. kernel-source... kernel-pcmcia... kernel-headers...
rpm -ivh kernel-2.4.1-0.1.9.i686.rpm
This way you have two kernels installed! "just in case (tm)"
If you have scsi, make your initrd
update lilo and run 'lilo'
Christopher McCrory "The guy that keeps the servers running" chrismcc@gmail.com http://www.pricegrabber.com
Read the manual, and next time, type dpkg --purge [package you want to get rid of] whenever you find yourself deleting a package.
Also, quite useful, try
As a final cleaning-up tool, install deborphan, a nice package that identifies libraries on your system which aren't needed anymore.dpkg --purge $(dpkg --get-selections|grep -E 'deinstall$'|cut -f1)
to get rid of those directories from older packages.
Yes. Some people like GUI tools.
GNU/Linux. The Freshmaker.
Do you have examples? What exactly is better with the Debian packaging policy? Otherwise this is just trolling... you can't just expect anyone to listen to "uhm, yeah, the package policy is great because apt is great and apt is great because the policy is great because..." with no explainations, and expect anyone to take you seriously.
2.Due to this consistency, apt-get and so on are made possible.
How does a packaging policy make a technology possible? Please explain. Otherwise, I think common sense says it's the other way around.
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.
What isn't likely to work? Some people have already made it work for you.
ie, the policy enables the technology to work.
Again, please tell why. I think a lot of people agree with me that you build a policy around the technology used - because if the technology doesn't support the decisions you make in your policy, then what good is the policy? The technology is the foundation for all your policy work - it takes more time to change the technology than make a slight change in policy.
I assure you that I understand the difference between the two, but I am not convinced that you understand the link... make sense?
Yes, I understand the link, but not why you believe the relationship is reversed.
GNU/Linux. The Freshmaker.
If you only have dial up access then why crap your pants over a security hole? Are there lots of nasty script kiddies on your LAN?
+++++
+++++
The harder you look the less you see. That's what we're up against.
Well, it's not our fault if ICQ requires other things. But why not either
.|` Clouds cross the black moonlight,
a) read through the list of requirements first so you're not stopping & starting to install icq?
b) use apt-get (or Debian altogether) where these dependencies will resolve themselves?
c) admit that things on Windoze also suffer from dependencies: "and then I installed OutlookExpress 98 and that didn't work either, but going to...".
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
modifying /bin/install is a bad idea. install is a well-known standard Unix utility, practically all 'make install' procedures rely on it; it's bad enough that there are BSD and SysV versions, don't add to the confusion. calling something besides install is a better idea. not all of the Unix world uses RPM. take the blinders off. thanks
Trying to compare RPM to apt-get is illogical. Debian's apt-get takes a package name and goes through your list of servers and looks for the package. The format of these packages is .deb. Apt will automatically get the .deb you requested plus any .debs it depends on.
Most other distros have standardized on the RPM package format-- possibly because a lot of them were originally based on Red Hat at some point in their life. RPM is a package manager. It serves the same purpose as the debian package manager (which is not apt). Unfortunately, there has not been an equivilant for Apt on RPM-based distros.
However, recently Connectiva or someone modified Apt to work with RPMs as well as DEBs, and if you read some of the other comments here supposedly it works pretty well. Also, Ximian (formerly Helix-Code) has come up with the new Red Carpet Updater. Red Carpet also serves the same purpose as apt. Unfortunately, Red Carpet is completely GUI from what I have seen and there is no command line equivilant. This kind of bothers me as it would be nice to use parts of it in scripts. On the other hand, it is free software so anyone could make some good command-line tools to go with it.
I have been using Red Carpet 0.9 since its release and I really like it. A big warning though: It does not like unsatisfied dependencies at all. In fact, I had NVIDIA_GLX (which depends on NVIDIA_kernel) installed but had no NVIDIA_kernel package because I rolled my own kernel and named it and the NVIDIA driver differently than usual. Well, because of this unsatisfied dependency (that is, NVIDIA_GLX depends on NVIDIA_kernel, but there was no packaged named NVIDIA_kernel on the system) it wanted to removed NVIDIA_GLX. And for some stupid reason it decided that it also wanted to removed all the XFree86 packages and other stuff. I of course declined and then eventually traced it back to having no NVIDIA_kernel package.
Basically I would say that Red Carpet is a bit to stringent about dependencies. On the other hand, this is designed to ensure the system stays stable. The bad thing is that I could just see someone following its advice (which I chose not to) and having it remove XFree86 and a bunch of stuff and then being unable to run Red Carpet to get it all back because it requires X. Whoops, must have forgetten a dependency there!
I suppose that is more than you wanted to know, but if you have an RPM based distro you should really check out Ximian's Red Carpet. And Petrely needs to get his damn head on straight and realize that RPM is comparable to deb and apt-get is something different. At this point with Ximian Red Carpet, there is basically now apt-get for everyone so this whole article is a moot point.
And oh, as another poster said, I rarely hear of any RPM users screaming that they want to switch to Debian. Personally I like RPM and from what I have seen of deb I see no reason to switch. The only good reason to switch to debian seems to be apt, but now that one company has made apt work with RPM and another has written a new program that works from the start with both deb and rpm I really don't see any reason to switch.
red-carpet works with debs too! (-=
You Like Science?
You Like Science?
You Like bottomquark.
Exactly how do you do the equivalent of apt-get upgrade in BSD ports?
Hmm . . .
:-) = I am happy
:^) = I am happy with my big nose
C:\> = I am happy with my OS
I am pretty sure that this is all still current - if you have a package that has been built as relocatable, you can specify a different database so that you can install stuff under /home/foo/bin...
Read up about it here among other pages. (This is the first one that I was able to find.)
+++ ATH0 +++
apt-get is "better" than rpm,
vi is "better" than emacs,
gnome is "better" than kde,
linux is "better" than *bsd,
my car is "better" than your car.
Why can't these people just s/better\ than/different\ from/g and realise that choice and diversity is part of what makes life interesting, and even if it wasn't, there still isn't one "right" answer for everyone.
Why do ppl think we would be better off with only one package manager? Different packages still have to be build for each system because of differing glibc versions and architectures etc (with exceptions for the very similar ones) so what do we gain?
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
blutgens@titanium:~> dpkg -S libGL.so xlibmesa3: /usr/lib/libGL.so.1
xlibmesa-dev: /usr/lib/libGL.so
xlibmesa3: /usr/lib/libGL.so.1.2
"If you love someone, set them free. If they come home, set them on fire." - George Carlin
It seems to me that they do leave a bit too much cruft on the system, by refusing to delete certain directories associated with a given app. We've all seen the error message saying (in essense) directory FOO is not empty, therefore will not be deleted. I don't know what apt's criterion is for this (I suspect they're being understandably overcautious) -- but I've seen inexplicable examples of this behavior when deleting programs I've never even used (eg. installing FOO and immediately de-installing it cuz it's taking up too much space), or programs that whose removal would have no possible effect on anything else. After awhile, you can collect quite a number of useless and confusing directories.
Again, I can appreciate the caution -- and having those remnant directories on my harddrive is a small price to pay for having such a wonderful, rock-solid distribution -- still, I wonder if maybe de-installing could be handled a bit differently. Instead of informing me that it's not going to delete a sub-directory, maybe they could code it so that it apt "asks" if I want to delete it. I'll switch to a different terminal, look through the files and make a "yes" or "no" choice. If I hose myself, I'll take my lumps.
Again, this is a SMALL quibble. The Debian team get nothing but lavish praise from this keyboard.
Yes, ncftp works perfectly well and just keeps trying until it gets in. What's your point? I never have to wait more than 5-10 minutes to get in.
I presume that apt-get allows some form of security checking (only allow these systems/servers in, only connect to those servers for updates, etc), because otherwise you're opening up scary big security holes.
In a production environment, automatic installs are definitely something that you have to worry about (either in the planning stages, or ongoing, or both). Suppose a patch comes down that fixes error A, but breaks function B in the process.
You'd never run it in a production environment, unfettered.
I would expect apt-get has some sort of flag/check in place to allow for when updates occur. Of course, on the backend, you could have control over what files are available for the clients to grab from, too.
Just thinking out loud. Pay no attention to the person typing at the keyboard.
By the way...
Moderating trolls and flames as "Offtopic" is Unfair and will be metamoderated as such.
From this section of the metamod FAQ:
I'm more concerned with the first 50 comments consistently receiving +3, +4, and even +5 bonuses when they really don't say anything of any substance. See the Napster Protection Scheme article for several examples. It seems like nobody reads the moderation FAQ or the metamod FAQ. I think the good moderators get fed up with the piss-poor moderators and quit, leaving only the bad moderators.
-- "Complacency is a far more dangerous attitude than outrage." -Naomi Littlebear
If it complains about any unmet dependencies such as shared libraries, you investigate your system to find out if those complaints are valid.
Or in my case, you forget about trying to install that mpeg viewer and go see what's on TV.
I installed many OS-es at that time just for the fun of it. Well, I just got my cble connection. ;-) They included Windows NT, Caldera, Slackware, RedHat (6.0 era), Mandrake, Debian, FreeBSD, NetBSD, and OpenBSD. All of them on one machine.
I almost spent more time on Debian than on the rest combined. First, it was not that easy to figure out what I needed to download with Debian. Second, it wiped out a wrong partition. Here is my original bugreport. OK, problems happen. However, I didn't get a reasonable answer in reasonable time. The first question was "Do FreeBSD do something peculiar?" Duh. I expect that the developers of the free Debian project know about other free operating systems. At the time it was too much. Finally Adam Di Carlo get in touch with me, and he definitely did everything to get it right. Hats off for his dedication. But it took a couple of months.
Second, their selection system was really unintiutive. Please keep in mind that it was in mid '99 so it might have changed since then. I read many horror stories about it, and I felt they were not baseless.
There is another reason I am not going to use Debian. Just yesterday I was pondering if I should give it a try again. (I am using RedHat and I am less than happy with them.) So I looked around Debian's homepage to figure out which kernel they officially support. I couldn't really find the info. OK, maybe I am too stupid. I am definitely (and not definately...) not a good searcher. Finally I logged into their ftp server and looked around. It seems that woody is using 2.2.17. Or at least this is the number I have seen in ftp://pub/mirrors/debian/dists/woody/main/source/b ase. At work we start to feel the bite of the 2GB file limit in the 2.2 kernels. The next distro I plan to use should definitely use the 2.4 kernels as default and not only as an quasi unsupported addon.
As I said, I would like to move away from RedHat. I am a guy who mostly works from the command line and use X only for browsing. I am not interested in linuxconf and co. But I definitely interested in a good package system which should be logical to use. Debian's back in '99 was really hard. Better said it was confusing. I also would like to use a system with up to date packages. I am not interested in the bleeding edge, like development kernels, but I didn't read anything about a serious problem with the 2.4 kernels. When will Debian support it? When 2.6 or 3.0 is out? When did they start to officially support 2.2? Why do we have to wait so long for it?
I don't exclude Debian from my choices. But what I have experienced was less that thrilling. Maybe I should take a newer look at Slackware. After all, this was my first Linux from "Using Linux" back in '95.
Vilmos
>>> gee, does that show version numbers of all packages? (this is the information i want), like this:
.glade files at runtime (Gno
Why, yes, it does. You challenge assuming you'll be shown correct, but as I stated before you don't know much about debian.
pileofcrap:~# dpkg -l |grep gno
ii gnome-bin 1.2.12-1 Miscellaneous binaries used by Gnome
ii gnome-control- 1.2.3-1 The Gnome Control Center
ii gnome-core 1.2.4-9 Common files for Gnome core apps
ii gnome-libs-dat 1.2.12-1 Data for Gnome libraries
ii gnome-media 1.2.0-2 Gnome Media Utilities (gmix, gtcd)
ii gnome-panel 1.2.4-9 Launch and/or dock Gnome applications
ii gnome-panel-da 1.2.4-9 Data files for GNOME panel
ii gnome-session 1.2.4-9 The Gnome Session Manager
ii gnomeicu 0.95.3-1 Small, fast and functional clone of Mirabili
ii libglade-gnome 0.16-2 Library to load
.
.
.
So there you have it. not only do you get version numbers, but you get brief descriptions. Much better. bahahah.
apt-get is just a frontend to a packet manager Uhm, I think you need to educate about what apt* is. It's a suite, not a single program. and apt-get is much more than a packet(package?) manager. Maybe coming from rpm land, your idea of a package manager is the most unweildy, bloated, inelegeant piece of hackery ever created to manage packages, but if that's the case I can only feel sorry for you. As a side note, I think the thrust of Nick Petreley's article is, why is debian (and corel maybe) the only distro with simple, elegant package retreival and maintainence. Not that "rpm and apt-get can't coexist" but more that they dont, and the big players dont want them to (for god know what reason).
"...but that's... my own fault. Apt-get rocks."
If you can blow your system away with it, how does that "rock"? The number one complaint about linux focuses on how usable, or not, it is for people who haveless technical backgrounds then most slashdot readers. If any package manager has the ability to toast your system, with out much doing, then I don't think it's what we really need. We need something that offers the power of RPM and apt-get for those users who know how to use it, but also something that's going to help out those newer to Linux. Hand holding for those less technically adpet and robust features for those who can safely use them.
When I try to install a package, It should go something like this.
Installing Package XXX.......
Checking Dependancies......
In order to install package XXX, Packages YYYY and ZZZ are needed.
Scanning for required packages.....
Packages not found, would you like to download and install these pacakges? Y
Downloading packages YYYY and ZZZ
Installing packages YYYY and ZZZ
Installing Package XXX
Done.
With a similar ease of use for uninstalls this would be perfect. I shouldn't have to know or even care what packages I need to install it should just all happen automatically.
I've used RPM a lot and deb a little. So far in my experience neither of them pulled this off consistantly.
Um, no. Hate to ask the oft-repeated request on slashdot to read the fucking article, but ...
If you do, you'll note that this is a dissertation on why apt-get is the One True Way Unto Happiness, and only mentions rpm in passing as a dependency check loop. A real comparison would have included similar utilities like rpmfind and Ximian's new Red Carpet and the pros and cons of each. Can we, in the future, label pieces extolling the virtues of $foo as such, and avoid extrapolating a salient comparison from the mere mention of $bar?
</rant>
(replace rpm with vi and apt-get with emacs, and read the article again.)
--
Actually, both my cable modem [home] and my OC3 [work] have lots and lots of bandwidth. They're also both pretty fast. So you see, Virginia, it can be a measure of speed.
What does annoy me is the slapping of the word "broadband" onto things which are not.
Would you rather the phrase be "dude, I've got lots of kbps!"?
--
Red Carpet is modeled after debian. And it's a front end. In fact I'd wager it's much easier to maintain the debian release of Red Carpet.
The message on the other side of this sig is false.
Yes it does.
The message on the other side of this sig is false.
Well yeah when someone does what you just told them you no longer have a reason to tell them.
The message on the other side of this sig is false.
Uninstall apt-get uninstall package.
The message on the other side of this sig is false.
What about dpkg -l somestring? It lists every package that is available in your distro-of-choice and matches the regexp "somestring".
Hello, my name is Robert Lerner, and I pronounce Lernux as "99% cpu"
Particularly nice is the capacity to have many different versions of any given product installed at the same time, each possibly with different dependencies (or dependencies on different versions of a different product). It is not only possible, but convenient for different users to run different versions by default, or even for a user to run different versions of the same program simultaneously, or switch back an forth between different versions. Very handy in a development environment.
Of course, it handles things like dependencies nicely as well. Unfortunatly, the only place I know of that distributes anything using UPS/UPD is Fermilab, and although they do make the UPS/UPD software available, they do not distribute software publicly using it.
'make world'
/usr/ports/freebsd/4.2
There is no "upgrade" for BSD's. And, I would rather not have one. Any OS (from Windows to Linux) I have ever upgraded, I format first (sans things like security updates). However, on FreeBSD, I am comfortable with just 'make world'.
So, to answer your question, no, you cannot say:
# cd
# make install clean
And, in the end, I would not want to nor would I ever do it.
Jeremy
There I was kidding around a little (not really funny though, even I can see that).. and you get all serious with me telling me that I'm missing the point?!
If you would have told me that I was offtopic when I moved the discussion completely to fruits I would have accepted that... but this... geeez...
--
Ner lbh sebz gur HFN? Gura lbh'ir whfg ivbyngrq gur QZPN!
apt-get does _NOT_ downgrade just because there are only older versions in its sources!
Nice try though...
--
Ner lbh sebz gur HFN? Gura lbh'ir whfg ivbyngrq gur QZPN!
to compare apt-get to 'rpm' is like comparing apples to oranges.
Ok... which of apples and oranges are preferrable... (ie more advanced / better functionality)?
--
Ner lbh sebz gur HFN? Gura lbh'ir whfg ivbyngrq gur QZPN!
I used redhat a lot when I started out with linux - redhat, and its derivatives (particularly caldera) for a long time. Then I moved to debian. Haven't looked back even once.
Correct me if I'm wrong but it seems to me that Ximian's Red Carpet project seems to do everything that apt-get does. It allows for searching of all kinds of servers for filenames, breaks up updates into categories like security or recommended, etc... It automatically resolves dependencies, allows for multiple server checking, AND it works for debian and rpm packages. In addition to that, it is GUI based so any newbie can use it safely and intuitivly.
This whole thing with rpm vs. apt-get is a moot point IMO since connectiva proved that apt can be ported to use rpm instead of dkpg. I do feel that apt-get is a really cool thing and that I hope more distros start using it. The big problem that would hinder this is that most distros would sell fewer "upgrade" boxes than before when people with fast net access can easily upgrade it themselves. But back to my previous point, integrate the rpm port of apt-get (which is a pretty large patch outside the normal apt tree) and stop trying to shout the highest wether rpm or dkpg is the best thing since sliced bread.
"The best way to impress people is to be very efficient and organised. That shocks people everytime." - h4rm0ny
I'd like to see a wrapper program that traps all system calls and maintains a reversible set of file system changes. In other words, I'd like to be able to say the following for any software
cd pkg
installer -p pkg make install
uninstaller -p pkg
and "the right thing"(tm) would happen. installer would record the changes being made in a way that could be rolled back. In fact maybe installer could produce an RPM.
/charles
Debian comes with a program that converts between the package formats listed in the subject line. Obviously, some info may be lost/generated in the translation, but it's better than nothing by a long shot. As an example, I've installed Sun's Java 2 SDK 1.3 on my Debian machine, by aliening their RPM to a Debian package.
The only way the typical /.er can pick up a chick is with a forklift. -- AC
I've never even heard of this problem, though I've been using SuSE since 6.3. But of course I don't really care either, as I tend to compile things myself anyway...
We're sysadmins, to us, data is protocol overhead.
Ecery Distro, hell every OS has there own way of updating.
If Linux sets a sertain way to update or upgrade it may stifle the groth of Linux, It may not do a thing but hell i will keep using the one that comes with the distro im using.
GPF : The program Win.exe has caused an erorr in
Microsoft's Windows Update feature doesn't use binary patches either, it's a download of compressed replacement files, exactly what you have to do with RPM, dpkg, slackware .tgz, etc. There are a number of good reasons for this, too. It's entirely possible for someone to miss an update or two or for an update to be reissued because of bugs. It's possible that shipping patches could end up being bigger than shipping the replacement.
I used up all my sick days, so I'm calling in dead.
>But I can't figure out how to list the contents of an rpm unless it's already installed.
rpm -ql -p package.rpm
-p specifies that you want to query a package file rather than the db of installed packages.
Now I'm no big RPM or Mandrake fanatic (ports! yay!) but the author of the article very obviously didn't do his homework.
URPMI is to RPMs as APT-GET is to DEBs.
http://www.linux-mandrake.com/en/urpmi.php3
You can also do scheduled security and package upgrades from the console with the MandrakeUpdateRobot (as mentioned in the forums). This is still labeled 'Cooker' software but supposedly it's going to be put into production very soon (a couple of weeks).
http://www.cyest.org/drakupdatetxt/
G. Washington on Government "it is force. Like fire, it is a dangerous servant and a fearful master."
I am sure that in both cases, that it is possible with either some switch settings or additional step somewhere.
I was wondering if the possibility of having a unified database for the packages might be reasonable, maybe an XML/RDF based database which then both apt-get and RPM can use mutally.
I was wondering if some of the concerns of those that aren't big fans of RPM are to use gnorpm and/or Redhat's Up2date. They seem to have some nice GUI aspects that make installing packages a little easier as well as providing for the ability to identify and install needed dependencies like apt-get does.
Or maybe some other tools like Auto Update or AutoRPM
Also would use of the package transalation tools like alien help in the two working together?
I think one of the concerns over all the recent hits on many of the distributions, which was one of the weaknesses in the Standard Linux projects has been inconsistant packaging. Perhaps, combining the projects may be beneficial to both parties so that other innovations and work can be done elsewhere.
BreezyGuy
Eric B
ebresie@gmail.com
I'm sure I'll agree with everyone else that this story is obvious, once I know what's going on.
--Colbey
I remember during the Debian pre-release days, Debian people putting a lot of effort, trying to arrive at a common standard for packages with RedHat/RPM at that time. It didn't work at that time when DEB and RPM standards were just being put together ... (Due to hesitations from RH side ?). Will it work now ? (Even though anyone can see that DEB based package management is far superior to the other scheme ...)
Gotta agree with ya there. In my experience the attitude has been more "if it ain't broke don't fix it" than "upgrade party this weekend! (as always)". In fact, most of the time you have to go out of the way to conciously say "uhhh, yeah we've put of upgrading such and such for too long" because the version they have been using is so moldy and stale that it has finally started to become a problem. Any place that has done a significant upgrade (and has any brains) learns really quickly that upgrades are a time and resource and productivity hog and that you really need a good justification for them.
I gotta say, I've seen both places, and worse, places that do both. For example, in the year and a half or so I've been at my current workplace, they've upgraded my PC 3 times. Now, that would be cool, except each time they've treated it like some lusers PC and broken all the stuff I need to do my job ("Oh, you can't just copy it and run it under Windows 2000?"). I would really prefer just getting a nicer monitor. On the other hand, some of the stuff I work on, trying to drag them up to a current supported level is near impossible. Sheesh. I guess it's the difference between a thousand things that cost a thousand dollars, and one thing that costs a thousand-thousand dollars.
Oracle and unix guy.
Nuhno! Wasn't trying to be some old condescending asshole! I was just commenting on how the ENTIRE 'net world used the term 'bandwidth'. Hell even I use it in that sense at times. Kinda wonder where it got started...
I first heard it used in that sense 20 years ago, and it was already well established. It comes from the basic copper-wire fact that the amount of information transmittable is a function of the width of the frequencies available. Telephones, for example, don't even send the male human voice fundamental. So since you can't increase the limit of width, the only way to increase the amount of information throughput is to increase its speed. So increasing the speed became interchangeable with increasing the bandwidth. Which, if you think about it, it is.
Oracle and unix guy.
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.
Does this mean that rpm and apt-get are merging anyways? That would moot Nick's whole arg.
Oracle and unix guy.
Modification of /bin/install is a good idea. I'm only suggesting that it look for an already installed program in its 'standard' location. Since most of these apps install themselves under /usr/local, that would be the reasonable place for an rpm to look for dependancies. If an rpm is dependant on a specific library it should, in this day and age, be able to look to see whether that library is available (the way configure does it, for example.)
:wq
Is it just me or did anyone else have to reread that story title before it sunk in. Maybe it's the capitalized On...
--
Yah know, I've been wondering that myself, lately. Repeat after me, the word is THROUGHPUT, kids.
:)
Pisses me off almost as much as nuke-yuh-lar. Which, incidentally, was how my 10th grade English teacher pronounced it until we gave him enough shit about it
--
There is no sin except stupidity -- Oscar Wilde
when it comes to querying the package database, debian's tools have no peer.
you can use dpkg for basic queries
you can use dlocate for some more queries like listing all man pages in a package (plus faster versions of some of the standard dpkg queries)
you can use apt-get and apt-cache for more complicated queries (e.g. to find out exactly what an upgrade would do if you issued the command, or to find out what packages depend on package foo, or to find out what package foo depends upon)
and if that isn't enough, you can use the wonderful grep-dctrl package to construct your own custom queries.
a simple example to show the Package name and version of any package that contains "bash" in the Depends field:
$ grep-status -s Package,Version -F Depends bash
Package: wdm
Version: 1.20-7
Package: sysprofile
Version: 0.2.7
Package: htmlheadline
Version: 21.8-1
Package: bug
Version: 3.3.9
Package: dlocate
Version: 0.5
Package: fmirror
Version: 1:0.8.4beta-2
Package: bash-builtins
Version: 2.04-9
you can do a lot more with grep-dctrl, including telling it not to output the field names. you can also feed it's output back into grep-dctrl (thus implementing an "AND") function, and you can pipe the output into other scripts as usual to do whatever you want with it.
I thought that you all already know that, Alfredo Kojima(The creator of WMaker) made a version of apt-get that works with RPM. It is been distribuited in Brazil by Conectiva(www.conectiva.com), and it works! I couldn't make it donwload the kde 2.01 but maybe it is just me. Why don't you all go there take a look?
I have no sig and I want to scream
I thought that you all already know that, Alfredo Kojima(The creator of WMaker) made a version of apt-get that works with RPM. It is been distribuited in Brazil by Conectiva(www.conectiva.com) and it works! I couldn't make it donwload the kde 2.01 but maybe it is just me. Why don't you all go there take a look?
I have no sig and I want to scream
Metoo, really sucks most rpm's in the world won't work because SuSe uses different RPM's. I think RPM would be a lot better if RPM packages would be compatible with each other.
(-% TwistedMind %-)
What's in that article about Storm linux being bankrupted? I can't find anything about it at the Storm linux website. I've installed Storm Linux on my desktop machine and I really like it.
(-% TwistedMind %-)
RPM is truly enterprise scalable and is much more of a "standard" than Debian apt-get. Shucks, 91% of the Linux world uses Red Hat, and subsequently, RPM. I suppose one could advocate Debian, but that time would be better spent further improving Red Hat, IMHO. Any thoughts?
Anyone happen to know how long SGI's software distributions using inst and swmgr have been around? Just asking for historical reasons.
Nuhno! Wasn't trying to be some old condescending asshole! I was just commenting on how the ENTIRE 'net world used the term 'bandwidth'. Hell even I use it in that sense at times. Kinda wonder where it got started...
GNU needs to break it up, if you ask me.
"If I were to ask you a hypothetical question, what would you like it to be about?"
Is it possible to downgrade your distribution from say woody/testing to potato/stable through dpkg's config files?
Why should people be loyal to a RPM based distribution? If they have RH 6.2, and find the 25 line bash session required to upgrade to kde 2.1 intimidating, are they going to wait until RH 7.1 is out?
No. They'll switch to the first distro that provides kde 2.1, and pcmag tells them is easy to install and use.
By having an unfriendly software installer, distributions provide a good reason for their installed base to abandon them. Assuming a user base is a good thing for those "long range plans", an easy to use installer is a key to success.
But apt-get will honor new versions from other sources. For example if I use the Mozilla debs from Progeny apt is more than happy to leave it alone. If I understand the first poster right up2date would force me back to a "official" version of Mozilla.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
I nuked my server with rpm -Uvh --nodep --force with libc6 and the 2.2 kernel. Oops. Maybe I should play around with apt-get... or is mv / /dev/null a better solution for me.
"After three days without programming, life becomes meaningless." - Tao of Programming
apt-get is a utility that lays on top of Debian's pkg manager - dpkg. Compare RPM to dpkg, but not apt-get to RPM.
I see no enlightenement in this article at all. First the author rants about a perceived corporate update cycle, labelling it some random thee letter acronym, then compares two dissimilar tools.
I don't know about most of you folks out there, but I have terrible bandwidth at home. I have to lug my machine in to the office after hours just to download updates. Just last night, I tried to download modutils-2.4.2-1.i386.rpm... a threehundred-something kilobyte file. I was reduced to tears when I found that I couldn't get past 145k downloaded before the connection would become so instable that the download would time out. .rpm, or a good 'ol .tgz or even a .deb that it would just list the deps and then point me in the direction to get them. I would at least like that functionality built into apt-get, or whatever package management utility that I decide to use at that time.
This phenomenon is augmented when you try to run an update util such as MandrakeUpdate or apt-get or up2date. I would just be happy if I had a utility that when I download an
I just want all the package management utilities developers to remember that a whole lot of folks out here have crap for bandwidth, and to use that knolege to try to come up with a viable solution
Oh, I'm sorry, did I offend you? You with such great knowlege? Should I have just kept my mouth shut? How about this:
:|
Me: "Well, I have terrible download speed thingy"
You: "Shut up, you don't know what your are talking about 100$3R!"
Well, excuse me for using a term that means that my "download rate" moves from a whopping 9 bytes/sec to all of 1.2kb/sec on a good day. Perhaps you would like to know my ping? Here you go... 1400! If you know so much, why don't you tell us idiots where to obtain such information, don't hoard it. Don't bitch until you give someone a chance. Have a nice day
gee, does that show version numbers of all packages? (this is the information i want), like this:
rpm -qa | grep gno
gnome-audio-1.0.0-7
gnome-audio-extra-1.0.0-7
gnome-core-1.0.39-10
gnome-core-devel-1.0.39-10
gnome-games-1.0.40-2
gnome-games-devel-1.0.40-2
gnome-libs-1.0.40-1
gnome-libs-devel-1.0.40-1
gnome-linuxconf-0.23-1
gnome-media-1.0.40-3
gnome-objc-1.0.2-5
gnome-objc-devel-1.0.2-5
gnome-pim-1.0.10-1
gnome-pim-devel-1.0.10-1
gnome-users-guide-1.0.7-1
gnome-utils-1.0.13-1
gnorpm-0.9-10
gnotepad+-1.1.4-2
pygnome-1.0.4-2
switchdesk-gnome-1.7.1-1
xmms-gnome-0.9.5-1
ound the message used repetitively over and over still nothing grows silen
problem was not this; i wanted to see the VERSION NUMBERS OF PACKAGES in the list.
Gee, i wonder can people actually READ?
ound the message used repetitively over and over still nothing grows silen
well, then, this is good! and as I said, i'm more of an Red Hat user, and well, FreeBSD too. I only tried to get the listings with apt, not with dpkg - i couldn't figure i need to use 3 different proggies for package management - dselect, dpkg and apt (whatever their relations are). and yes, I don't know much about Debian - I only played with it for couple of weeks.
ound the message used repetitively over and over still nothing grows silen
ok. i'm a redhat user, but i've tested debian, just to see the wonders of apt-get. one missing feature from apt-get, is the rpm -qa | grep somestring i get the list AND versions of packages with 'somestring', which I couldn't do with apt. i could query the whole list of packages, but it doesn't show versions. i get the version only by querying some one specific package. also, i had problems installing all the necessary header-files to compile programs, 'cause the .deb's that had the headers were conflicting each other. of course, this is not a problem of apt, but problem of packagers - and seemed like .deb's had lower quality than rpm's - more conflicts with packages and so on.
ound the message used repetitively over and over still nothing grows silen
One of the great things I love about Linux is that every one does something a little different. So I pick and chose from each distro until I get exactly what I want. No one should be forced to use a particular tool or method. If I wanted that I would have stayed in commercial *nix.
well, everywhere where i have worked has definitely had upgrade mania.
--
I think RPM as a package manager is useful enough for the average user. But its a big headache to resolve package conflicts and dependencies. Everyone that uses RPM knows that, and sometimes you just have to download/install packages that you dont really want to upgrade to resolve those deps.
Another thing that you probably want to do, if you use RPM, is to have backups of those package/deps/provides,etc database files. Just in case. Couple days ago I upgraded rpm from version 3 to 4 and bombed those db files. All files in the provide list were gone and i couldn't install any without doing --nodeps.Search for 'alien' on freshmeat, or go to the homepage or simply:
;-)
#apt-get install alien
-Helmet
I understand what you are saying and I am sure that I would always want to compile things for myself because I usually want to hack the configuration, hack the source, compile in my own options, read the source...or whatever. However, this may be good for my workstation where I like to run the latest stuff but for a company that has say a hundered servers or a novice user who understands jack...it is not very powerfull enough.
The beauty of package management tools is that they do so much more than just install a binary. These are a list of things I would really like in a package management tool:
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
True, true. Any method will reflect a choice based on available resources, and CVSup is not the right method for every set of circumstances, such as the sets to which you allude. My opinion of CVSup is that it is a top-notch implementation of a solution to the particular types of problems it was designed to solve.
I hope anyone whose impressions may be formed from my post takes my seeming denial of the truism that nothing is perfect and the smiley face at the end as an obvious hyperbole implying a strong, but not quite as universal, compliment to Mr. Polstra. Used in the right circumstances, CVSup is, in my experience, extremely fast and mistake free.
-Scott
"Frederick, is God dead?" --Sojourner Truth
This article chimes in on the latest euphoria about 'apt-get' and the related bashing of RPM. Let me explain why I think Mr Petreley has no clue ...."
# 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)
Furthermore, I've been told that apt-get was standard tool in latest Cooker aka Mandrake 8.0beta.
Why RPM and DEB couldn't create an extra database for each user, that would, with the datas grabbed from the main RPM database (the one installed as root), manage the user's packages installed in his home?
You're right, and Petreley may not know that to keep your RedHat Linux up-to-date auto'ly via the Internet you pay them a yearly subscription to their "up2date" service so obviously there are ways to make money with this. (i may have gotten a detail wrong here [eg, w/subscription length] but that's basically it.)
"Be thankful you are not my student. You would not get a high grade for such a design
Not only this, but the inability to download binary patches is a serious flaw in making Linux an OS suitable for the desktop. If anyone out there is serious about making Linux a competitor to Windows, BeOS, or OS X, an incompatible morass of update mechanisms requiring compilation of source is a major problem.
The only certainty is entropy.
...like buying a Ford instead of a Chevy because you like the door handles better on the Ford.
...like voting for a presidential candidate based on who has the better hair.
Like buying a Ford instead of a Chevy because the Ford is faster.
Like voting for a presidential candidate based on who has a better performance record.
Lets get the facts straight before we go making assinine comments about how one is better than the other without actually using both systems and making a fair opinion based on what you've learned. So don't tread on people because you lack information.
And I don't want to fuel it, but isn't it interesting that only/mostly debian users want deb to become the defacto standard? I haven't heard of many rpm users wishing to switch to deb.
Plus the author of the article does not seem to get the difference between apt and deb. And apt is being ported to use RPM (I believe that conectiva's linux distribution does this). Plus there's red carpet, rpmfind etc.
Now, I understand the advantages of a unified packaging/distribution format, but why not apt-deb and not apm-rpm? What about slackware or stampede?
A single format (like a single desktop) would wield some significant advantages. But isn't linux all about choice?
The only problem that i've got with debian (I'm a redhat user), is that it essentially requires a fast, cheap and permanent connection to the internet in order to get all the packages up2date (no pun intended). I don't have that connection (and not many people do outside the US).
you happen have an internet download and also happen to need DCHP support and drivers for a NIC which isn't on the list! Then you might as well forget about making the distro anything better than a disastro! Or at least that is my (very recent) experience with apt-get.
political_news.c: warning: comparison is always true due to limited range of data type
Perhaps you are unaware of the existance of SuSE? Last I checked, they're the most LSB compliant distro out there.
One of my misgivings with the RPM system is it's inability to determine later versions of software if installed compiling it yourself... for instance, the latest ppp utilities, and any of the latest and greatest reiserfsprogs. An RPM with any earlier versions of this software will stomp all over your more up to date install. Same thing with the RPM based up2date... it insists that my kernel needs to be updated.... from 2.4.2 to 2.2.17. Yea. Is apt capable of determining file/package versions? If not, as troubling as RPM deps can be, it isn't enough to make me change distros.
up2date is, of course, RPM based and absolutely does not "rawk". If the RPM is not in RedHat's database, or the database it is pointing to, it assumes that you are out of date, even if the package was installed via RPM. For instance, installing package superprog.2.4.5 from anyone but redhat, then redhat will come back and say "no no" you need our version 2.2.7 our whatever. LAME
Alein, you can find it on freshmeat.net, will convert from redhat to debian, slackware to debian, debian to redhat, slackware to redhat, slackware to debian and slackware to redhat :-) -- a pretty awesome util if you ask me.
RPM more stable than apt-get... I haven't tried apt-get, but RPM is definatly the worst packaging system I have tried. If you are looking to compare package systems you really shouldn't ignore the best. check out pkgtool (get slackware). I found RPM to be the stupidest part of redhat.
I've been playing with Mandrake cooker a bit this week. Expect to see a feature like this provided by the urpm package. You tell it where to look for RPMs and it builds a catalog of what everything provides. Then it will manage installing everything you need for a given package.
But I have to admit - I installed Ximians red-carpet tool after throwing RH7/2.4.2 onto a new desktop and was really impressed. Its great to have everything - pick it choose it install it. Heck after I put RH 7 in, I used red-carpet to update another 90MB of packages. Very nice. - yes it still has dependency problems and I've found the rpms are not cutting edge - but good enough.
I'm sure apt-get is wonderful, but I found this article concentrated on just the low level stuff without looking at the GUIs cropping up for package mgmt and talking about how that effects the equation.
Personally, I could care less which pakcage manager is used - as long as it can get me current stuff that is easy to install. Don't get me wrong - I don't shy away from source compiles (I used HP-UX for years and anyone who has tried to compile stuff on HP-UX knows how difficult it can be given the 'unique' library layout) But RPMs/apt-get make for easy upgrades when you don't have to stay cutting edge :o
--
Top Most Bizarre/Disturbing Error Messages
I've been using Conectiva Linux 6.0 for the past few months and have been very happy with it. Conectiva uses apt with a rpm backend (as opposed to debs) which is great since it gives you all of the pluses of both formats. The ease of use of apt (and it's wonderful dependency checking) and the compatibility of RPM (let's face it, it's the better represented of the 2 formats.) Also, you can still use RPM seperately from apt to install and query packages. I wish that more of the distros would adopt this way of doing things instead of fighting over which one is better. Just use both :)
I used Debian about 2 years back when apt-get was taking off, and it felt like a tool more intended for fast connections. I live in an area where cable/dsl is not easy to get (and expensive), and so I must use 56k modem. Compounding the problem is that it's common for the connection to break while dialed-in, so I can't just start a download and walk away for a few hours thinking it will reliably complete.
After checking dependencies and determining what files to get, does apt-get download all the files first to a temporary directory before it starts installing? If so, if my modem connection breaks during file download is there a way to check the files in the partial download that's already been done and get the remaining files? Or must I start the whole thing over to do it in one pass?
Or, can apt-get just check dependencies and make a list of the files needed such that I could go to another machine on a LAN, download the needed files, transport them back to my machine on a zip disk, copy them to the hdd, then point apt-get to that directory holding the files?
There is an apt-get version, which handles rpms. Can't remember its location though.
You can use Alien to the conversion between the different package formats.
-- The plural of 'anecdote' is not 'data'.
Here's the output from "man urpmi":
[...]
Just launch urpmi followed by what you think is the name of the package(s), and urpmi will:
- Propose different package names if availables and quit.
- If found only one Package corresponding, check wether dependencies are already installed or not.
- If not, propose to install the dependencies and then install all required dependencies and the package.
[...]
Note that urpmi handle installations from various medias (ftp, local and nfs volumes, removable medias such as CDROMs) and is able to install dependencies from a media different from the package's media. If necessary, urpmi asks you to insert the required media.
Not to mention that now I have been building Mandrake Update Robot console daemon for a periodic & automatic RPM upgrade in a large network. Click here for the sample report 2001-02-25.txt - which is e-mailed to the system administrator. It also checks for GnuPG signature from Linux Mandrake Security Team and the MD5 sum of it. Mandrake Update Robot is currently still v0.8Beta1 and under development day 8. If you wanna see what has changes, here's the ChangeLog The next version of Mandrake Update Robot will even compile your own custom kernel directly if there's a kernel upgrade.
So, please do a little bit more research before comparing RPM vs apt-get. If you want to compare apt-get, compare it with Redhat's Up2date or my Mandrake Update Robot, or Mandrake Update & rpmdrake (GUI) and urpmi (console).
Thanks,
Fishycat.
I think everybody knows that redhat is one of the, if not the most widely used linux distro out there. I'm just curious as to where the fuding for providing a free apt-get service to throw out RPM's to thousands of users would come from? I'm sure that Debian may have some problems, but compared to redhat the user base is fairly small. Bandwidth does equal cash after all.
.. Was 'Red Carpet' ever made? It would have been easier to use apt, since it has been ported to rpm.
Same goes for that KDE update thing, and all the other redundant tools.
Or am I totally missing the point here?
@ .
make
make install
and to uninstall- make clean
Cross platform and always better than rpm or apt
dlocate works too!
Oops, I went off on a bit of a tangent then but I hope you see what I mean.
Each package manager has its own merits. People will always use which ever they prefer. Personally, I don't have a permanent net connection so the full benefits of apt-get is lost on me.
Claric
--
There's no problem that cannot be solved with a suitable amount of high explosives
...that we started taking the power away from Red Hat in making the standards for Linux. People must be reminded that Red Hat is NOT the only Linux distro, and I think I speak for most of the Slashdot community when I say that RPM just plain sucks compared to apt-get.
I, for one, am sick and tired of RedHat's "standards."
Is your company running tools written by ma
Maybe a minor issue, but it's Petreley and not Peterely as is mentioned in the story (and even the headline). |R
Hey Guys, Just think about it for one second. Nick Peterly is right. If all the distributors got together and decided to create a common base installation which was always easy to upgrade, it would do wonders for linux. SO many more people would adopt it as a platform since the frustration that often goes woth updating your OS would be negligible. I set up and maintain servers running red hat and sometimes upgrading is such a pain. With apt-get its so easy. If only debian or progeny would clean up their installs. There is no reason for debian users to have ulcers while red hat and mandrake can set up such a clean, easy install system. I know debian is striving to be the Professional's Linux Distro but come on, no matter how good the OS is you cant use it if you cant install it.
Do you fellows even know what you are discussing
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.
dpkg -S IIRC
:)
At uni, so not a debian box atm
but yes. But you can't have file by file dependancies as you can with rpm.
I've only briefly seen BSD in action and only quickly played with apt-get source .... but...
:)
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
Petreley says "On the other hand, consider the business implications of selling a distribution based on Debian: the distributor would be adopting a system that is deliberately designed to make it nearly impossible to sell its customers any upgrades. That cuts off a primary source of revenue for the Linux distributor." I thought the linux-distros made money from service, not from the media they sell. I mean, I realize the software they include is free, but they have to pay someone to package them, customize them, etc, etc. Not to mention all the production and marketing-related costs. How much profit is left when boxed sets sell for $20-30 on Wal-Mart's shelves ??
Nevermind Debian's political stances (they're the choir at the High Church of Emacs :); that itself can be overcome.
:); when I need to use linux, it is still my choice. apt-get is wonderful; I never hated dselect (except for the refuasal to fix a bug that locked it over telnet because the bug was in ncurses), and a single /etc for everything is great (though I understand the reasons for having separate locations).
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
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...
If you're not part of the solution, you're part of the precipitate.
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 ; 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." :-)
If you're not part of the solution, you're part of the precipitate.
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. :)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Thats what apt-get does to. If you haven't pointed it to the right place, it can't find the packages.
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
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
> The biggest problem I've had with rpm, IMNSHO, is its inability to deal with dependancies of non-rpm packages on the system.
> 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
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
What has always amazed me about RPM packages is that the builders always seem to remove their brains before making them.
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...
A Government Is a Body of People, Usually Notably Ungoverned
The world's perfect OS is Slackware with ports. Too bad it only exists in my imagination.
A Government Is a Body of People, Usually Notably Ungoverned
That *is* a nice feature, but it only works if the package is already installed. What if you're trying to compile something and ./configure says you need library foobar.so.0 and you don't know what rpm it's in? Is there a way to query the rpm database to find out what rpm to install? Otherwise, you have to go get the source for the library and compile it up as well. Or guess what rpm it's in.
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?
Admit nothing, deny everything and make counter-accusations.
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.
GNU/Linux. The Freshmaker.
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.
GNU/Linux. The Freshmaker.
I love the question of the poll on the front page:
::grin:: )
"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
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Also, RPM is clearly much easier to use and seems more stable, at least to me.
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 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?
Have you ever tried to get soemthing from RedHat's ftp server?
Several people have mentioned that you can get the list of files owned by a package with dpkg -L . This is true.
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.
--
I am a Debian user and I *love* my apt-get. BUT, it only works seemlessly if you stay strictly with official debian sources in your /etc/apt/sources.list file. If you don't, you run the possibility of having package name collisions.
/etc/apt/sources.list file. Both Debian and Ximian have a package called "sawfish-gnome", and both use different versioning schemes. Ximian's sawfish-gnome depends on sawfish. Where as Debian's sawfish-gnome conflicts with sawfish.
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.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
What I still dont understand is why linux keeps reinventing the wheel. Why not simply use the ports/package tree from the bsd's?
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 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!
GPL'd web-based tradewars themed space game
I'm sorry, but it seems nobody here is actually aware of the current status of APT:
* 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.
Does the apt system maintain a database of what files belong to what packages?
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?
www.eFax.com are spammers
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
The best application management device yet invented is the NeXT bundle (which Apple has capitalized on with OSX). Bundles localize application resources (internationalization, icons, pixmaps, etc) to a single directory, and considerably reduce dependency problems. And they do not rely on a central database that can bring down an installation if corrupted or destroyed (a la windows registry). For more info, check out John Siracusa's reviews on OSX at ArsTechnica.
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
No. Up2date is available for all users. If you download redhat, you can use it.
I love Debian and apt don't get me wrong, but what I thought was silly is how dpkg and apt require perl. I like perl too and all but recent perl troubles with the packages in unstable have been a mess and if I wasnt more carefull dist-upgrade would have removed perl and that would have left me with a busted system. What exactly is perl used for, the install scripts on the packages? If its possible it would be nice to get rid of the perl dependancy alltogether and make apt and dpkg statically linked binaries because they can be broken and leave you high a dry.
:))
Still kicks RPM's ass though
How much is apt-get alike the ports collection from the BSD versions? This is because I really enjoy the easy of installing under ports. What I've been told it also does the downloading/checksum/patching/configuring/make/mak e install in one go. apt-get however, does this in a seperate command whereas ports have a directory structure for it.
I would like to see an objective review of these two "packaging" formats. Any comments?
This is a replacement signature.
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.
---
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Let me get this straight,
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?
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
Am I the only one that dislikes the common usage of the term "bandwidth"??
*sigh*
Kiddie: "I've got LOTS of bandwith"
Clued: "Oh, really? What, rom 20 KHz to 200 MHz?"
...how an increase in GNU/Linux choices often leads to increased arguing over which should be The Best and The Standard? And eventually, a whole boatload of choices usually results in one being pushed down everyone's throats? Distros outta ship with earplugs.
Ah, hell... just use an Amiga or an SGI.
rr
Quidquid latine dictum sit, altum videtur.
rr
Quidquid latine dictum sit, altum videtur.
- 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
Quidquid latine dictum sit, altum videtur.
Also last time I looked (Granted this was several months ago) up2date only worked if you bought a boxed set from RedHat. It did not work with any other way you could get RH this is one of the things that made me give Debian a try and I'm *very* happy that I did because I have found far more since then.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Gotta disagree with you there. While I've seen the kind of shops you describe, they have generally been a rarity. Unfortunately, the majority of IT departments I've run across, suffered from a bad case of the DUH's. In my own insignificant experiences I've seen three seperate companies destroyed by upgrades gone horribly wrong simply because they had to have the latest and greatest.
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,
"The words of the prophets are written on the Slashdot walls."
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.
--
Accountability on the heads of the powerful.
Power in the hands of the accountable.
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. This collection of makefiles is 'refreshed' each time 'live' when you update your ports collection. This way you have all the 'latest' build procedures for every app who cares to register itself (for your particular BSD & version). When you want to install an application - you execute this makefile (which builds your app and resolves deps (by building those)) it does this by FTPing the necessary sources from the appropriate location.
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'.
Slashdot has a discussion about this the apt-rpm project here
What i have described above may be all completely wrong - but this is how I understand it. Please correct me if this is so.
Gotta agree with ya there. In my experience the attitude has been more "if it ain't broke don't fix it" than "upgrade party this weekend! (as always)". In fact, most of the time you have to go out of the way to conciously say "uhhh, yeah we've put of upgrading such and such for too long" because the version they have been using is so moldy and stale that it has finally started to become a problem. Any place that has done a significant upgrade (and has any brains) learns really quickly that upgrades are a time and resource and productivity hog and that you really need a good justification for them.
I tried to apt-get an upgrade to xfree 4. It didnt work. I installed a binary, and now apt, naturaly, is broken, probably beyond all repair.
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.
I've discussed this with some linux using friends of mine before. Debian is a non-profit company and Redhat is here to make money. What does that have to do with anything, you ask? Debian users upgraded from 2.1 to 2.2 with a one line command. That was it, that simple, nothing to it, and it was almost a non-event. If you're not understanding, they upgraded their entire box, every library, binary, etc to become debian 2.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?
"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).
"...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."
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
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
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.
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
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.
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.
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.
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.