Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
| |||||||||||||
|
| |||||||||||||
Do we need this crap on LWN?Do we need this crap on LWN?Posted Feb 21, 2007 16:17 UTC (Wed) by markc (guest, #4419)In reply to: Do we need this crap on LWN? by cartman Parent article: ESR's goodbye note
Yes, it all might help the RH/Fedora folks abandon rpm and standardize on
(Log in to post comments)
Do we need this crap on LWN? Posted Feb 21, 2007 16:41 UTC (Wed) by evgeny (guest, #774) [Link] Right. One may or may not share ESR's sentiments about [not] supporting non-free multimedia formats; however, the adherence to RPM is truly a shame for a distro. When the deb-versus-rpm flaming heats the zillionth time, one sees the RPM proponents trying to prove it's not less capable/reliable/... than deb. Even if true (though I've yet to see anybody stating it on oath) this would be absolutely insufficient to justify its existence - given that apt-get existed prior to RPM emergence.
Do we need this crap on LWN? Posted Feb 21, 2007 17:11 UTC (Wed) by ofeeley (subscriber, #36105) [Link] Well, there seem to be a lot of changes already happening around RPM after a period of relative stasis: http://wiki.rpm.org/Docs/RpmOrgFAQ
So an alternative to dumping the whole thing is to fix whatever needs to be fixed and it seems like there's a serious effort going on to do that.
It's worth pointing out that for all the hysteria spread about RPM (and dependency resolvers/updaters built on top of it -- such as YUM), it mostly just works if you're just using it to stay current with updates of packages _within_ each release. The issue of doing live upgrades from one version of Fedora to another is something that it would be nice to work out http://fedoraproject.org/wiki/YumUpgradeFaq, but it's doable as long as you're willing to troubleshoot.
Do we need this crap on LWN? Posted Feb 21, 2007 17:19 UTC (Wed) by evgeny (guest, #774) [Link] > Well, there seem to be a lot of changes already happening around RPM after a period of relative stasis: http://wiki.rpm.org/Docs/RpmOrgFAQ
This FAQ doesn't answer the principal question: what key features are going to be in RPM that don't currently exist in deb/apt-get?? or cannot be added with a lesser efforts to deb??
Do we need this crap on LWN? Posted Feb 21, 2007 18:11 UTC (Wed) by TwoTimeGrime (guest, #11688) [Link] I'm a long-time Debian user but one feature in RPM that's not in the deb system is the ability to check the integrity of an installed package. With RPM I remember I could run with an option and it will see if all the packages files still were installed and would check the MD5SUM of each file against the package database. It was an easy way to check if files from a package were missing or corrupted. It helped me when once on a RH 7.x machine I accidentally ran "rm -rf /usr". I was able to find out what files were missing and then reinstall all of the relevant packages.
Despite research and asking other debian sysadmins I could not find any options in dpkg to handle this.
integrity checking Posted Feb 21, 2007 18:28 UTC (Wed) by rfunk (subscriber, #4054) [Link] apt-get install debsums
integrity checking Posted Feb 21, 2007 19:38 UTC (Wed) by sandy_pond (guest, #9734) [Link] I don't think this has much to do with RPM vs debs as much as this link:
http://in.sys-con.com/read/278818.htm
"One of the co-founders of the open source movement has become the member of the Freespire Leadership Board. Freespire is a community-driven, Linux-based operating system that gives users the option of combining free open source software with certain proprietary codecs, drivers and applications. Raymond, well-known as both a theorist and an advocate for the open source movement, joins twelve other Freespire Leadership Board members, composed of thinkers, business people, evangelists, and key members of the Linux community."
integrity checking Posted Feb 21, 2007 20:52 UTC (Wed) by muwlgr (guest, #35359) [Link] I use debsums and I would like to note that .md5sums file is optional for .deb packages, unlike .rpms where I think md5sums are mandatory and could always be verified by rpm -V.
integrity checking Posted Feb 22, 2007 0:25 UTC (Thu) by TwoTimeGrime (guest, #11688) [Link] > apt-get install debsums
Thanks, but that highlights another think I dislike about debian. There are too many commands for package management. Now I have to remember dpkg, dpkg-query, and debsums along with all of their different options to manage my packages. At least with RPM systems there's a single command and options to remember which is just "rpm". Also, why isn't debsums' functionality built into the package management system by default? And why isn't debsums installed by default.
integrity checking Posted Feb 22, 2007 3:24 UTC (Thu) by drag (subscriber, #31333) [Link] Well you don't have to remember anything.
Use wajig tool or the jig interface.
It's a python package management system that does it right. It basicly takes the functionality provided by all these little tools and utilities and makes a nice little user-friendly interface for it.
For example to backport a package from testing to stable you'd go like this:
wajig update
For instance I did that with OpenAFS server since the newer version in Testing was much better then what was aviable by default in stable. Took a whole 10 minutes to download, compile, then install the package.
Also I could of easily then taken the package and installed it on a bunch of machines.
The python bash-completion stuff works for it in testing. So if you go:
Or you can go:
Also it has intellegent handling of agruements with trying to do best effort match to your command to a certain extent.
will do the same thing.
Also you can do search through package names using tab.
And not only is the thing written in python and is convient to use.. it is QUICK. Very quick. Because the UI is in python were speed is not critical, but on the heavy calculating stuff it's all done by the little C programs that it's a front-end for.
That's the nice thing about Debian.
It's tools are small and contained. Just fast little utilities. Why have everything in some huge monolythic application? It just makes it buggy and difficult to use.
BTW this is the functionality you can get with wajig + debian package tools.
A lot of people prefer not to use front ends and use the tools directly, but I am lazy like that.
addcdrom -- Add a CD-ROM to the list of available sources of packages
""Also, why isn't debsums' functionality built into the package management system by default? And why isn't debsums installed by default.""
Probably because there is little need for it to be installed by default.
With Debian Etch signed packages are going to be used by default. This will ensure that they are not tampered with and are not corrupt. This is the most important reason why you'd need checksums...
There are lots of little things that make your life easier.
Like for instance 'deborphans'. Which uninstalls unused dependancies that may have been installed by a package you ended up removing later.
Or for example: localepurge.
Localepurge can be used to remove locales and localized man pages. It can save many hundreds of megs of disk space, maybe even a gig or two on a machine with a lot of stuff installed. Once you run it then it will automaticly be ran after installing or upgrading packages.
This stuff seriously kicks-ass. Most of the time the functionality of Yum is fine.
But Yum's slowness can be a huge pain. At my work I use a old 600mhz machine. A update using yum got interrupted halfway through becuase I ran out of disk space on / (my mistake).
I was there fixing it from 1 am to 5 am in the morning and the majority of the time was spent on waiting on yum to painfully go through it's motions. It was very very painfull to watch. Even with the -C switch it was painfull.
If it was Debian, and not CentOS:
would of fixed it in about 3 minutes.
integrity checking Posted Feb 22, 2007 5:44 UTC (Thu) by k8to (subscriber, #15413) [Link] wajig is pretty fantastic. I wish it had become the standard instead of aptitude, and as a result was a bit more maintained.
There are some pretty simple glaring bugs with wajig that have gone unfixed for a lonnnng time. wajig show package fails if it is no longer downloadable but currently installed. apt-cache shows it fine. Huh?
Yeah I should submit a patch but sorry the other 15-odd patches I've submitted about other debian tools have come first.
apt in CentOS (was: integrity checking) Posted Mar 1, 2007 4:24 UTC (Thu) by topher (guest, #2223) [Link] Just a note, if you enable the CentOS Extras repository on a CentOS 4.x box, there is an apt package available. You can enable it, use yum to install it, and then use apt to manage your packages from then on.
Definitely worth it, IMO. ;-)
Do we need this crap on LWN? Posted Feb 21, 2007 18:14 UTC (Wed) by pizza (subscriber, #46) [Link] Okay, here's a key feature dpkg+apt is lacking that RPM has had for some time now:
* Sane multi-lib support.
Do we need this crap on LWN? Posted Feb 21, 2007 23:07 UTC (Wed) by proski (subscriber, #104) [Link] Not quite. "yum install foo" will install both foo.x86_64 and foo.i386 and all dependencies for both. I expect it to install foo.x86_64 only. Apart from that, it's mostly OK.
Do we need this crap on LWN? Posted Feb 22, 2007 8:08 UTC (Thu) by bojan (subscriber, #14302) [Link] So, run "yum install foo.x86_64".
Do we need this crap on LWN? Posted Feb 21, 2007 18:37 UTC (Wed) by foo (guest, #1117) [Link] I prefer debs, too, but one thing I missfrom my RPM days is the ability to query which package owns a particular file.
E.g.:
# rpm -qf /etc/diameter/sunping.xml
which package owns a file Posted Feb 21, 2007 18:50 UTC (Wed) by rfunk (subscriber, #4054) [Link] dpkg -S /etc/diameter/sunping.xml
which package owns a file Posted Feb 22, 2007 15:00 UTC (Thu) by foo (guest, #1117) [Link] Great, thanks!
which package owns a file Posted Feb 27, 2007 23:00 UTC (Tue) by cdmiller (subscriber, #2813) [Link] Yeah but whats up with this?
dpkg -S /etc/passwd
Whereas:
which package owns a file Posted Feb 27, 2007 23:15 UTC (Tue) by rfunk (subscriber, #4054) [Link] That's a generated file rather than one installed from a package. (The base-passwdpackage generates it, but I realize your point is about how to get that information.) The easiest way I know to get that sort of information is to grep the files in /var/lib/dpkg/info/.
Do we need this crap on LWN? Posted Feb 21, 2007 19:16 UTC (Wed) by fmarier (subscriber, #19894) [Link] To search in your installed packages:dpkg -S /usr/lib/libxml2.so.2
To search in all packages (installed or not), first install the "apt-file" package, then run:
Do we need this crap on LWN? Posted Feb 21, 2007 19:48 UTC (Wed) by vondo (guest, #256) [Link] Since we've got deb experts reading this... The thing I miss from rpm days that I don't know how to do in deb/apt is:
rpm -qa --last
Give me a list of all the packages installed and order them by the last time they were updated.
dpkg magic Posted Feb 21, 2007 20:55 UTC (Wed) by rfunk (subscriber, #4054) [Link] I don't think a capability like that is built in, but try this:ls -ltr /var/lib/dpkg/info/*.list | sed -e 's,^.*/\([^/]*\)\.list,\1,'
dpkg magic Posted Feb 21, 2007 22:06 UTC (Wed) by jonabbey (subscriber, #2736) [Link] Ah, but what would Eric say about such an unfriendly, regressive, inward-focused approach to software design?
Okay, yeah, sorry, I've got nothing.
Do we need this crap on LWN? Posted Feb 22, 2007 5:46 UTC (Thu) by k8to (subscriber, #15413) [Link] Until _quite_ recently this was completely impossible. Really. No records were kept at all.
Now that dpkg keeps a log, someone could at least write such a thing, although I don't think one exists yet.
dpkg log Posted Feb 22, 2007 14:41 UTC (Thu) by rfunk (subscriber, #4054) [Link] the ls/sed hack I posted above works on Debian sarge, which (although current stable)isn't exactly "quite recent". No need for the dpkg log. And as far as I can see, recent dpkg only keeps a log if you explicitly tell it to anyway. (Though I could be missing something more recent.)
dpkg log Posted Feb 22, 2007 18:21 UTC (Thu) by k8to (subscriber, #15413) [Link] Buh, I didn't look at the criteria closely. I've often needed a log and found the 'most recent update' information was too lossy.
Do we need this crap on LWN? Posted Feb 22, 2007 16:49 UTC (Thu) by akumria (subscriber, #7773) [Link] Something like:
eve:[~]% sudo tail /var/log/dpkg.log
perhaps?
Do we need this crap on LWN? Posted Feb 21, 2007 22:50 UTC (Wed) by mrons (subscriber, #1751) [Link] How about:
yum localinstall somerandom.rpm
Do we need this crap on LWN? Posted Feb 22, 2007 0:55 UTC (Thu) by mrons (subscriber, #1751) [Link] > yum localinstall somerandom.rpm
Just to expand on what this does, yum looks at what dependencies somerandom.rpm has and installs those with somerandom.rpm
somerandom.rpm does not have to belong to some {un}official repository.
So it's like "rpm -i" except that repositories are consulting to resolve dependencies.
Can I do something like "apt-get somerandom.deb" and have dependencies resolved for me?
Do we need this crap on LWN? Posted Feb 22, 2007 1:51 UTC (Thu) by spotter (subscriber, #12199) [Link] not directly.
if you
dpkg -i some.deb
that will try to install it, but it wont configure due to missing dependencies.
and
apt-get install -f
will then fix it as it will resolve the missing dependencies and configure everything.
Do we need this crap on LWN? Posted Feb 22, 2007 5:47 UTC (Thu) by k8to (subscriber, #15413) [Link] I use wajig as my do-everything debian package tool. It supports 'wajig install <packagename>' as well as 'wajig install ./a_package-3-3_i386.deb'
Do we need this crap on LWN? Posted Feb 22, 2007 0:01 UTC (Thu) by mmarq (guest, #2332) [Link] "" This FAQ doesn't answer the principal question: what key features are going to be in RPM that don't currently exist in deb/apt-get?? or cannot be added with a lesser efforts to deb?? ""
hmm ... better would be what misses in both, and or what can be improved in both.
well i remenber GoboLinux... its so damn easy that is hard to belive
But of course, many "commercial" apps already big on other environments, and that Linux would be needing to get a strong foot inside the workstation/desktop arena, arent going be be distributed in source code :(
But then again solutions appear like if by magic...
So, imho, what Linux need is a crossplatform installer capable of dealing with RPM and deb, and also capable of installing from source code... if only InstallJammer could implement that source code feature!... it would be perfect.
Do we need this crap on LWN? Posted Feb 21, 2007 22:59 UTC (Wed) by markc (guest, #4419) [Link] But if the folks pushing RPM are considering improvements, after it'sdevelopment was almost abandoned for a few years, then it would be a major plus for all of linuxdom if they wholesale dropped rpm altogether, adopted the deb system, and then added what they feel might be missing to debs. Then in one 1/2 year painful changeover period for rpm users (maybe, maybe not) we'd have more than 75% of the linux distro universe using the same package format and, also, Debians current huge and well organised repositories would be INSTANTLY available to RH/Fedora users. That would do more, in 6 months, to unify "linux" everywhere than all the talk and LSBing we've had this century. Right now is such a golden opportunity for RH/Fedora to make one of the most sensible changes, tht they have not even contemplated, with the largest positive outcome for all concerned.
RH/Fedora and spinoffs would gain a packaging system that already has the
Do we need this crap on LWN? Posted Feb 22, 2007 0:40 UTC (Thu) by ofeeley (subscriber, #36105) [Link] "RH/Fedora and spinoffs would gain a packaging system that already has theessential improvements they seek"
What are those improvements that are desperately sought by us? Without the slightest trace of smartassedness I don't know what I'm missing. I have used yum for quite a while now and am very happy with it (I haven't bothered to look at pirut or pup although I did use pup's predecessor up2date for years). I've had a few problems but not many and nothing that I couldn't fix relatively easily.
"AND a huge swag of ready made packages"
The fedora repositories already have a huge swag of ready-made packages, just from within the officially blessed Core and Extras (which have now merged). If you add in unofficial repositories then it looks like there /may/ be a slight advantage of around 10% in terms of numbers of deb format packages as previously discussed: http://lwn.net/Articles/222681/
"(minus the ongoing transitional RPM package format nightmare, possibly for
What is this transitional nightmare? In all seriousness I've never heard of it.
Do we need this crap on LWN? Posted Feb 22, 2007 3:30 UTC (Thu) by markc (guest, #4419) [Link] > What are those improvements that are> desperately sought by us?
FWIW, I can only speak from personal experience. I inherited control of a
> The fedora repositories already have a
Nyah nyah, my deb fanboy thing is bigger than your rpm fanboy thing. The
> What is this transitional nightmare?
The current stability of the rpm system is because it has not been
The underlying point is that there is an ever so minute opportunity to
Do we need this crap on LWN? Posted Feb 22, 2007 5:42 UTC (Thu) by bojan (subscriber, #14302) [Link] > I inherited control of a CentOS 3.6 vhost and was told on some Plesk forums it was not possible to upgrade to CentOS 4.3 (me gobsmacked).
There is a reason for not being able to upgrade a running system using "yum upgrade" - it's udev. It removes the old dev package during upgrade and your system dies.
Otherwise, it's a perfectly doable thing. You could even script it using kickstart. Done many upgrades of RHEL3 to RHEL4, completely unattended.
> One of the reasons this won't happen is because of rpm fanboyism, as you have clearly demonstrated, so "we" shall remain a fragmented group of fanboys.
See: http://kitenet.net/~joey/pkg-comp/
For instance, Debian packages cannot track file dependencies, something that distributions like Fedora rely on heavily. Actually, Fedora packaging policy is to prefer dependencies based on what the build process determines, rather than manual ones, which can be easily forgotten. Good or bad, that's the Fedora way...
Do we need this crap on LWN? Posted Feb 22, 2007 6:42 UTC (Thu) by markc (guest, #4419) [Link] > There is a reason for not being able to upgrade> a running system using "yum upgrade" - it's udev.
So in the case of a CentOS 3.6 -> 4.3 upgrade it would not be advisable
> See: http://kitenet.net/~joey/pkg-comp/[1]
11. Some people consider file dependancies a gross misfeature.
Do we need this crap on LWN? Posted Feb 22, 2007 7:52 UTC (Thu) by bojan (subscriber, #14302) [Link] > So in the case of a CentOS 3.6 -> 4.3 upgrade it would not be advisable for an inexperienced rpm user to upgrade a remote vhost.
Oh, it's absolutely advisable. Just use the upgrade process (anaconda runs that). You just can't do it while the system is hot.
> 11. Some people consider file dependancies a gross misfeature.
And, quite obiously, some don't.
Do we need this crap on LWN? Posted Feb 22, 2007 11:53 UTC (Thu) by markc (guest, #4419) [Link] > Oh, it's absolutely advisable. Just use the> upgrade process (anaconda runs that).
What is anaconda and would it be included in a CentOS 3.6 system ?
> You just can't do it while the system is hot.
There we go, the aspect of RPM management that is "desperately needed"[1]
[1] Refer to previous comments above.
Do we need this crap on LWN? Posted Feb 22, 2007 15:51 UTC (Thu) by pizza (subscriber, #46) [Link] > What is anaconda and would it be included in a CentOS 3.6 system ?
Stick the CD in, it boots up. That's anaconda.
> here we go, the aspect of RPM management that is "desperately needed"[1]
You're confusing "The RPM tools" with "The Debian Packaging Guidelines as implemented using the dpkg tools". Get your comparison straight.
> I have one box that has been up for 464 days and started with a Debian Sarge 2.6.12 devfs enabled kernel and now runs a Ubuntu Dapper udev enabled system, on the same kernel, without a reboot... the very excuse I was given for why upgrading from CentOS 3.6 to 4.3 was not possible. It seems that unless RPM based folks actually use a Debian based system they no not what they are missing out on.
"RPM-based folks" are apparently missing out on a lot of remote exploits and possible filesystem corruption!
I reboot my machines every 90 days (if not sooner due to power outages or whatnot) solely to install new kernels and run disk integrity checks.
I don't give two hoots about SERVER uptime; to me SERVICE uptime is all-important, and I achieve that with redundancy and performing test upgrades on non-critical systems in advance.
Do we need this crap on LWN? Posted Feb 22, 2007 16:41 UTC (Thu) by markc (guest, #4419) [Link] > Stick the CD in, it boots up. That's anaconda.
Great, but not on a dedicated host 10,000 miles away.
> You're confusing "The RPM tools" with "The Debian
I think I'm comparing the use of any number of (unfamiliar to me) rpm
> "RPM-based folks" are apparently missing out on a
Some would argue it's not appropriate to have such file system checking
http://packages.debian.org/cgi-bin/search_packages.pl?key...
> I don't give two hoots about SERVER uptime; to me
Dare I suggest that if you used a Debian based distro you could go live
Do we need this crap on LWN? Posted Feb 22, 2007 17:18 UTC (Thu) by pizza (subscriber, #46) [Link] >> "RPM-based folks" are apparently missing out on a>> lot of remote exploits and possible filesystem corruption!
>Some would argue it's not appropriate to have such file system checking
No; I was referring to the fact that you can't fsck a live filesystem, and that it's an unfortunate fact of life that filesystems are at best only as reliable as the disks they run on -- errors silently happen.
For me, periodic reboots serve two purposes -- Perform filesystem consistency checks, and install updated kernels (I am quite glad the 2.6.x.y series exists!)
It's more commonly known as scheduled preventative maintainence, and through the use of multiple physical systems, I avoid service downtime. (Even with virtualization, the host system needs occasional TLC too!)
> Dare I suggest that if you used a Debian based distro you could go live and stay live with less redundancy and pre-testing.
Been there, done that, been burnt by it. As I've alluded to many times in my posts here, it's the policies that you follow that ultimately matter. I discovered the hard way that using Debian didn't make things any simpler for me -- It just had a different set of quirks to watch out for.
Granted, this was a few years back, and Debian has addressed quite a few of the problems I had at the time... but as I've also said, if I don't see any tangible benefit to making a change, why bother?
Do we need this crap on LWN? Posted Feb 22, 2007 20:01 UTC (Thu) by bojan (subscriber, #14302) [Link] > Great, but not on a dedicated host 10,000 miles away.
You missed the unattended upgrade bit above. The one with kickstart.
Let me repeat again. This particular limitation (of not being able to upgrade CentOS 3 to CentOS 4 while running) has nothing to do with RPM. It has to do with the fact that CentOS 4 (i.e. RHEL4) uses udev and CentOS 3 (i.e. RHEL3) uses a dev package. When dev gets removed by upgrading to udev, your system is hosed (you have nothing left in /dev).
Otherwise, I've done plenty of hot upgrades by doing "yum upgrade" on many different versions of Fedora.
> which is the point that ESR seems to have finally stumbled upon in the head article
He stumbled upon his on inability to manage his own system and/or ask others how to do it.
Do we need this crap on LWN? Posted Feb 22, 2007 20:15 UTC (Thu) by loening (guest, #174) [Link] Speaking of remote upgrades with RPM. I personally have doneRH8->RH9->FC1->FC2->FC3->FC4->FC5->FC6
On a workstation that sits 300 miles away from me that I haven't seen in years.
dev => udev Posted Feb 25, 2007 14:54 UTC (Sun) by smurf (subscriber, #17840) [Link] So please enlighten us poor souls who have *no*idea* why you'd need to "clean out" /dev when moving to an udev-based system. Why not leave the old package-supplying-/dev-nodes installed?
You can mount a tempfs onto /mnt/whatever, create the bare essential device nodes there, move-mount that to /dev, and start up udev. (In fact, this is how a udev-based system boots in the first place.)
Total downtime for programs attempting to open /dev/null (or whatever): Zero.
Afterwards, if you do want to remove the old /dev-supplying package, well ... RPM has a --justdb option.
dev => udev Posted Feb 26, 2007 4:27 UTC (Mon) by bojan (subscriber, #14302) [Link] > why you'd need to "clean out" /dev when moving to an udev-based system
Well, if you run "yum upgrade", it is a fact that that's is what's going to happen: upgrade to udev will remove dev, which will remove all entries in /dev.
As you explained, it is not necessarily what needs to happen - but it does by default. So, unless you're prepared for some creative surgery (as per you explanation), you will get screwed.
Coming back the original question of supported upgrades from CentOS 3 to 4 (or RHEL 3 to 4), it is obviuos why this is not a recommeded thing to do - people don't normally want to recommend a complicated and risky process that would in the end require a reboot anyway (new kernel). RHEL packages were designed to be upgraded using the upgrade process, not "yum upgrade" (remember: RHEL 3 and 4 don't even ship yum, it's a CentOS addition).
You can find some more info here (search for udev):
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manu...
Note how you have to be on 2.6 kernel before starting this. CentOS 3 (i.e. RHEL 3) is based on 2.4 kernel.
Instead, one cuts a small kickstart file, starts an upgrade and after some minutes has a fully upgraded system with far less risk of stuffing things up.
Do we need this crap on LWN? Posted Feb 22, 2007 13:18 UTC (Thu) by ofeeley (subscriber, #36105) [Link] "I recently got a VPS with Debian3.1 installed, within 2 weeks I upgraded it to Ubuntu Dapper then on to Debian Etch (v4) then back across to Ubuntu Feisty (because Debian doesn't have a nanoweb package) with zero manual intervention."
If (as is probable from you calling it a VPS) it's a SWsoft/OpenVZ/Virtuozzo based VPS then the problem that you describe will definitely occur _if_ the hosting provider hasn't made the right templates available.
The only way that major upgrades across kernel versions can work with that sort of virtual server is if the kernel (and related infrastructure like the /dev/* stuff, glibc etc) that are pulled down when you do an update are matched by changes in the hypervisor.
The lack of upgradability of one CentOS version to another is more an issue of what your VPS hosting provider has made available than any limitation of rpm.
I don't know if the same limitations apply to other virtualisation techniques (Xen, kvm etc). I have experience of exactly the problem you're describing and it irritated me, but I blame the hosting company ;)
I can only assume that either you had pinned the kernel in your migration to/from various Ubuntu versions, or the hosting provider had templates available for all those versions.
Thanks for the rest of your clear and detailed answer.
Do we need this crap on LWN? Posted Feb 22, 2007 13:35 UTC (Thu) by ofeeley (subscriber, #36105) [Link] "One of the reasons this won't happen is because of rpmfanboyism, as you have clearly demonstrated, so "we" shall remain a fragmented group of fanboys."
It's a pity you ruined an interesting post with a personal attack. I don't think that asking for particular information as to the specific advantages of a system that I'm largely unfamiliar with, and correcting your mistaken impression that there are few rpm packages is fanboyism. I agree that a single packaging format would be useful in terms of reducing apparently duplicated effort.
Do we need this crap on LWN? Posted Feb 22, 2007 14:13 UTC (Thu) by markc (guest, #4419) [Link] > It's a pity you ruined an interesting post with a> personal attack.
Thanks for pointing that out, I'll try and keep a more impersonal
>> FWIW, I can only speak from personal experience.
This was a dedicated host with a kernel that probably came default with a
>> I recently got a VPS with Debian 3.1 installed,
This was indeed a recent experience on a Virtuozo VPS with a 2.6.9 kernel.
>> I have one box that has been up for 464 days
This one, I think, is a custom rolled kernel with devfs compiled in and I
Do we need this crap on LWN? Posted Feb 21, 2007 17:41 UTC (Wed) by drag (subscriber, #31333) [Link] I don't think that it's a issue with RPM vs deb for package format technical superiority.
From my limited understanding RPM is superior to Deb and it always has been.
The difference is the quality of the packages being made themselves. For a long time third party rpm files were created in a very ad-hoc/loose fasion and that reflected very badly when people tried them.
As for upgrading between releases by doing 'yum update' or 'apt-get update && apt-get dist-upgrade' is a difference of culture. In Debian this is valuable so they work hard to make sure it works, in Fedora they prefer just to let anaconda take care of the incompatabilities between releases.
I don't think either approach is wrong, although I think that Debian approach has advantages to end users. Then again Debian still hasn't gotten a stable release out and it's been a cronic problem so it's not like Debian's approach isn't without problems either.
Do we need this crap on LWN? Posted Feb 21, 2007 18:31 UTC (Wed) by rfunk (subscriber, #4054) [Link] While I agree that the main difference is culture and care, I disagree that RPM istechnically superior. dpkg has the "partially-installed" status, preventing the database corruption that RPM is famous for.
Do we need this crap on LWN? Posted Feb 21, 2007 22:29 UTC (Wed) by drag (subscriber, #31333) [Link] Ya that is nice.
Plenty of times I've had to cancel a update to a debian box halfway through and to recover from that only took a minute or so of work.
Do we need this crap on LWN? Posted Feb 22, 2007 20:40 UTC (Thu) by eklitzke (subscriber, #36426) [Link] FWIW...
The only problems I have had with RPM have been circular dependencies (this not recently). This can, of course, occur with dpkg as well -- it's a problem that is symptomatic of poor packaging, not the package manager. OTOH, I have had issues with dpkg on a number of occasions. In particular, dpkg is not as strict about making sure that everything is going to work, and at least twice I have had failed dist-upgrades that broke the system, because half way through the upgrade dpkg panicked somewhere and left my system half broken. RPM is pretty paranoid in its transaction checks, and will not put you in this position.
Also: dpkg cannot install multiple versions of a package simultaneously. RPM can do that, portage can do that, I don't see why this huge feature has been neglected by the Debian community for years.
A long time Fedora user, I have recently been using Ubuntu because of a few big packages not present in Fedora that would be too onerous to maintain myself. I have been pretty pleased so far, but I still am not impressed with dpkg, especially given the niceties of RPM (and yum).
Do we need this crap on LWN? Posted Feb 23, 2007 7:52 UTC (Fri) by drag (subscriber, #31333) [Link] ""Also: dpkg cannot install multiple versions of a package simultaneously. RPM can do that, portage can do that, I don't see why this huge feature has been neglected by the Debian community for years.""
I don't understand that and how that works.
In fact it caused major problems for me when I tried to use CentOS that I'd end up with multiple packages installed somehow with no easy way to get rid of them.
Say I have one program that depends on libfoo.3.2 and I have another program that depends on libfoo.3.5 with the libfoo project introducing incompatabilities in their lib files on minor numbers (As many projects do).
Does having multiple packages of libfoo installed automaticly make both programs work? I have no idea.
I mean I've been using Debian for years and I never ever had a desire to install two copies of the same program at the same time...
Do we need this crap on LWN? Posted Feb 23, 2007 23:28 UTC (Fri) by eklitzke (subscriber, #36426) [Link] Normally this is used for things that aren't libraries. For example, you might want to have multiple kernels installed, multiple versions of MySQL, multiple versions of Python, etc. I think if you were careful you could do this with libraries as well, but I'm not sure how intelligent RPM would be wrt overwriting symlinks. As it stands, Debian based distributions include the package version as a component of the package name, to get around the limitation. This is why, for example, on Ubuntu there is currently a python2.4 and python2.5 package. In an RPM based distribution there would just be a bunch of python packages in the same repository, and by default the newest one is installed -- if you need an older version and it is in the repository, it can be pulled in by another package's dependencies, or you can specify the version you want to install at the command line. This is a useful feature, and there are yum extensions (e.g. installonlyn) that use it in interesting and creative ways.
Do we need this crap on LWN? Posted Feb 22, 2007 8:58 UTC (Thu) by gilboa (guest, #23856) [Link] ... ARGH!
We (as in the Fedora community/users/maintainers/core developers) do not need to justify -anything-.
Why do you even -care- if RedHat/Fedora/Mandriva/SUSE continue to use RPM? What is to -you-?
- Gilboa
Do we need this crap on LWN? Posted Feb 22, 2007 9:07 UTC (Thu) by evgeny (guest, #774) [Link] > We (as in the Fedora community/users/maintainers/core developers) do not need to justify -anything-.
Sure. It's such a nice hobby - reinventing the wheel. Especially a square wheel - so there must be two types of roads built parallel everywhere.
Do we need this crap on LWN? Posted Feb 22, 2007 9:25 UTC (Thu) by gilboa (guest, #23856) [Link] ... Hey, while you're at it.Why do we need vim and emacs? Evolution, kmail and thunderbird? Firefox, Epiphany and Konq? GNOME, KDE, E17 and XFCE? BSD and Linux?
I, for one, rather have my own choice, thank you.
Oh... and I for one, rather have an RPM based system then a deb system.
- Gilboa
Do we need this crap on LWN? Posted Feb 22, 2007 11:14 UTC (Thu) by evgeny (guest, #774) [Link] You confuse the choice of _applications_ with multiple incompatible _standards_. The latter is devil - which everyone in a sane mind knows (besides MS and, apparently, you). "Firefox, Epiphany and Konq" are fine as far as they don't invent HTML extensions. IE, on the other hand, is known for doing exactly that. And so whoever decided to invent RPM when deb was already there, should be similarly ashamed. I don't believe RH will switch to deb now - it's too late, but a gross mistake remains a gross mistake. And I strongly believe the reason was only to distancing from Debian in any possible way. At a much later time, when the choice was whether to go yum or apt-rpm, they picked the inferior (can't say now, but certainly by then) yum. Same reason.
deb "wasn't already there" to be used. Posted Feb 22, 2007 15:36 UTC (Thu) by pizza (subscriber, #46) [Link] > And so whoever decided to invent RPM when deb was already there, should be similarly ashamed.
I'm having a hard time finding actual dates, but from what I can find out:
http://www.debian.org/doc/manuals/project-history/ch-deta...
dpkg was developed during 1994, but the first "public" release of debian with dpkg didn't happen until March 1995 -- 0.93r5.
http://fedoraproject.org/wiki/History
RPM was first used in RHL 2.0 Beta, publically released in the summer of 1995 but the immediate predecessor of RPM (RPP) became publically available in RHL 0.9 on October 1994. PMS was another package system that was used in the BOGUS distribution, and the brains behind RPP and PMS merged the best of both to create PM then RPM shortly afterwards.
So while technically Debian/dpkg was publically available before RHL/RPM, dpkg "wasn't already there" to be used when RHL1.0/RPP (and PMS) was released, nor while RPM was being developed.
Using your logic, "whoever decided to invent dpkg when RPP and PMS were already there should be similarly ashamed."
deb "wasn't already there" to be used. Posted Feb 22, 2007 18:00 UTC (Thu) by evgeny (guest, #774) [Link] > So while technically Debian/dpkg was publically available before RHL/RPM, dpkg "wasn't already there" to be used when RHL1.0/RPP (and PMS) was released, nor while RPM was being developed.
I really don't know whether RPP should count (i.e., how sophisticated it was), especially given that RPM wasn't backward compatible to it (then you can also count the primitive package management system used by Debian in 1993 and still get a one year off).
Do we need this crap on LWN? Posted Feb 25, 2007 8:50 UTC (Sun) by rganesan (subscriber, #1182) [Link] > Even if true (though I've yet to see anybody stating it on oath) this> would be absolutely insufficient to justify its existence - given that > apt-get existed prior to RPM emergence.
I am a Debian developer but I am responding in defence of RPM, go figure ;-). First, apt-get did not pre-date RPM. Second, apt-get cannot be directly compared to rpm. rpm package equivalent is a deb package and rpm binary equivalent is dpkg utility. apt-get operates at a level higher than dpkg and automatically handles dependencies among other things. Connectiva ported apt-get to rpm and I prefer it over yum to administer the odd Redhat machine we have at work.
As a format, there's not really much to choose between rpm and deb. They both work well. In fact, there is a consistency in rpm command line that I like better than dpkg (for e.g. dpkg --listfiles and dpkg --contents vs rpm -ql and rpm -qlp). I also like the fact that source rpms are also rpms.
Why redhat invented yum when apt-get was already out there is still a mystery to me. However, yum or apt-get is still not the real issue. Even debian apt-get has trouble mixing and matching many repositories. I have had trouble installing some packages from Ubuntu universe/multiverse because the packages in those repositories don't meet the high standards of the code. The real issue is the quality of the underlying packages and the number of available packages.
And _that_ gentlemen is where Debian really shines. Debian is extremely anal about getting even the most trivial details in a package right. If you make the smallest typo/grammar mistake in your package description you get a bug. If you get your dependencies wrong, or doesn't handle upgrades correctly that's a severe bug. It's this attention to detail and the availability of all the packages in the core that makes Debian a winner.
Do we need this crap on LWN? Posted Feb 25, 2007 14:01 UTC (Sun) by evgeny (guest, #774) [Link] OK, thanks for clarifications. I stand corrected.
> Connectiva ported apt-get to rpm and I prefer it over yum to administer the odd Redhat machine we have at work.
And so do I...
Do we need this crap on LWN? Posted Feb 21, 2007 16:41 UTC (Wed) by k8to (subscriber, #15413) [Link] While I think debs are better too, I don't think the kind of reliability you're comparing here is really deb's prowess really. It's more a matter of lots of slogging through hammering out solid policy and enforcing it.
Do we need this crap on LWN? Posted Feb 21, 2007 19:02 UTC (Wed) by malex (subscriber, #15692) [Link] You got it nailed. Compare the debian-mentors mailing list's tradition oftaking apart every presented package to the uncharted eons of badly made rpms and it becomes clear that quality control is what makes Debian upgrades so painless.
Do we need this crap on LWN? Posted Feb 22, 2007 9:31 UTC (Thu) by gilboa (guest, #23856) [Link] A. Official Fedora repositories (Core, Updates, Extras) share the same mentor's like program. (AKA: Package review and sponsor process).B. Once you go 3rd party (unofficial repos), it's your own ass to fry. (BTW, last time I tried to install freenx on my Etch system [from a 3'rd party repo] I almost ended up with a dead Debian system - Somehow you don't see me blaming deb for my own mistakes.)
- Gilboa
Do we need this crap on LWN? Posted Feb 21, 2007 18:19 UTC (Wed) by TwoTimeGrime (guest, #11688) [Link] You are confusing the apt system with debs. Debs are the packages just like RPMs are packages. Debian-based distros use the apt tools to resolve dependencies. RPM people use a program called yum to resolve dependencies.
Here's a list of how things are similar (debian <-> redhat):
debs are similar to rpms (the packages)
Do we need this crap on LWN? Posted Feb 21, 2007 18:23 UTC (Wed) by tialaramex (subscriber, #21167) [Link] "I've always used deb systems and was only recently totally, I mean totally, blown away that is was not possible to upgrade a CentOS 3 something system to the latest version without reinstalling from scratch."
I've been upgrading Red Hat and Fedora systems for the best part of a decade now, most recently I did the FC5 to FC6 upgrade just a few months ago on several of my PCs, and for most of that time clueless Debian fans have been telling me that it's impossible, even when I'm doing it right in front of them. I doubt that CentOS (being largely a Red Hat source re-spin) is missing this feature, but if it is that's no reason for Red Hat or Fedora users to think RPM is defective.
ESR isn't interested in Free Software, this latest "goodbye note" is more of the same from him, Fedora is cited as bad because it didn't include non-free components, even though Fedora was /explicitly/ about Free Software. As others have already noticed, ESR is hardly a disinterested party here, he's now on the board of directors of a corporation which explicitly wants to push proprietary codecs into desktop Linux.
Do we need this crap on LWN? Posted Feb 21, 2007 19:15 UTC (Wed) by ofeeley (subscriber, #36105) [Link] I've only done FC4->FC5 and then FC5->FC6, but a few people seem to report going from much earlier versions:
Using YUM:
Using APT:
CentOS3 is a rebuilt from source version of RHEL3 (which in turn was based on RHL9), so it's probable that it can be done.
Do we need this crap on LWN? Posted Feb 21, 2007 20:24 UTC (Wed) by mokki (subscriber, #33200) [Link] I have done upgrades from RH 7.1->7.2->7.3->8->9->FC1->FC2->FC3->FC4 until the hardware failed a year ago. I used whatever was the best method available at time, rpm --freshen, up2date or yum upgrade.
In each upgrade there were always 4-10 packages that prevented a clean upgrade. Usually they were external rpms that the official rpms were trying to replace but ended up conflicting, but there were also bugs in the dependency and especially in the replacement information in the official rpms.
I remember that at one upgrade I managed to break the whole rpm database (whose format has changed many a time) and had to basically install most rpms from scratch (but even then I did not do any upgrade/install from cd).
But claiming that rpm is poor because removing a library can break it is, while correct, what happens to all other package management systems.
I have also broken my gentoo installation by installing a broken glibc (which I luckily was able to recover from by running /bin/ash and copying from a still open nfs mount the required files). And gentoo packages never even try to warn you that the removed package would break half of the system.
My understanding of debs/apt has always been that it is a good technology, but that the culture behind the packaging is the only thing where the major differences comes from. On the other hand now that I had my first few experiences with debs a month ago while trying to compile them for N800 (arm target) I just could not believe that there really was no way of saying that I wanted to enable FPU instructions globally in CFLAGS but I had to patch each and every package separately. So it might be that the final debs are easy to use and work with, but the I found the building system for creating them very much lacking (or at least the documentation).
Do we need this crap on LWN? Posted Feb 21, 2007 21:24 UTC (Wed) by bojan (subscriber, #14302) [Link] > RH 7.1->7.2->7.3->8->9->FC1->FC2->FC3->FC4
For me, it was RHL 5.0 all the way to FC6, at which point the hardware died. Pretty good run, if you ask me!
Do we need this crap on LWN? Posted Feb 22, 2007 6:09 UTC (Thu) by k8to (subscriber, #15413) [Link] Realistically you can swap out libraries that are fundamental.
Programs that are already running already have the old library open, and new programs that depend upon the new library will open the new file. I have upgraded libc many times on Debian with nary a hitch. Deb addresses the all-at-once instant or nearly-instant changover between one coherent state and the next.
This _does not_ address the problem that a program may open a library late for whatever reason (SIGSTOP, dlopen), which usually results in a segfault but could be worse in some situations. It's plausible that this improvement might not look good from where you sit.
In practice though, Debian updates everything on the fly except the kernel and everything is fine. (A new kernel can of course be installed on the fly, but not loaded.)
Do we need this crap on LWN? Posted Feb 22, 2007 8:17 UTC (Thu) by bojan (subscriber, #14302) [Link] AFAIK, this is a kernel feature. As long as there is something using an inode, the kernel won't let go. So, existing programs are OK and new ones pick up the new stuff. Upgrading things like glibc is safe with RPM in my experience (although you can have unexpected trouble if you update components of X11 while running yum from an X11 session, as X11 may die on update).
However, from the thread, I gather that ESR booted his box without that crucial library. And or course, the system was hosed.
Do we need this crap on LWN? Posted Feb 22, 2007 14:03 UTC (Thu) by k8to (subscriber, #15413) [Link] Right, the inode-based filesystem makes this (mostly) transparent. But rpm's approach to file updates (used to) prevent the update of base libraries from being achievable on running systems.
Maybe it got fixed in the 5 years or so since I gave up SuSE, but I assumed it had not given your above comments.
I concur the problem here was rm important-file.
Do we need this crap on LWN? Posted Feb 22, 2007 14:05 UTC (Thu) by k8to (subscriber, #15413) [Link] Oh, and I've certainly updated X from 6.8 through 7.1 while running it without a hitch. I'm still convinced dpkg handles this slightly better. But it may just be prejudice on my part.
Do we need this crap on LWN? Posted Feb 22, 2007 20:07 UTC (Thu) by bojan (subscriber, #14302) [Link] > But rpm's approach to file updates (used to) prevent the update of base libraries from being achievable on running systems.
Going back to something like Red Hat Linux 7.2, this worked just fine. Upgraded glibc (remotely) many times. I honestly cannot remember before that...
Do we need this crap on LWN? Posted Feb 23, 2007 7:11 UTC (Fri) by mokki (subscriber, #33200) [Link] Swapping of glibc at runtime works nicely on all distributions.
As I said the only time I (almost) hosed my system was when I installed a broken glibc. After that you can no longer start any programs and you have to hope you have enough of needed terminals/other programs open that still refer to the old working glibc to recover the situation. The worst thing is that with a broken glibc no distribution tools can install/restore you to safe state again.
Do we need this crap on LWN? Posted Feb 22, 2007 9:53 UTC (Thu) by tyhik (subscriber, #14747) [Link] "As far as I know it is not possible to create a static binary that does not somehow depend on the glibc (or some other critical library)."
It is. Static binary is indeed self-contained and to run it just the ABI-compatibility with the underlying kernel is needed.
Do we need this crap on LWN? Posted Feb 22, 2007 13:13 UTC (Thu) by nix (subscriber, #2304) [Link] ... unless it does name (service, network...) resolution, in which case you need the nss libraries from the version of glibc the program was built with.
Do we need this crap on LWN? Posted Feb 22, 2007 9:00 UTC (Thu) by gilboa (guest, #23856) [Link] "CentOS3 to 4.4"
... Which has -nothing- to do with RPM and everything to do with Anaconda. I'd really suggest you get the facts right -before- you start spreading FUD.
- Gilboa
Do we need this crap on LWN? Posted Feb 22, 2007 10:31 UTC (Thu) by bojan (subscriber, #14302) [Link] > This message from ESR really rubs it in.
The only thing this message rubs in is the fact that he made a mistake on his own system (after being properly warned), didn't know how to use the rescue disk, didn't have an up-to-date backup and then came to the list blaming everyone else for the problem he created. Very uncool.
> not possible to upgrade a CentOS 3 something system to the latest version without reinstalling from scratch.
Completely not true.
Silly rpm vs deb flame war Posted Feb 22, 2007 12:43 UTC (Thu) by nicku (subscriber, #777) [Link] That is absolutely pathetic in the 21st century... all the more so since there is a much better alternative. And to think the LSB depends on RPM!!! There is no technical reason why rpm repositories cannot work as effectively as deb repositories. The reasons are social and political. The Debian repositories are carefully tested to be consistent; dependencies are carefully worked through. The Debian repositories are remarkably complete, so there are few repositories that are not part of this cooperative effort to produce a coherent whole. Red Hat repositories are not nearly as complete as Debian's, so there is a need for third party repositories such as dag, freshrpms, atrpms and all the rest. Red Hat employees considered their efforts to be of insufficient quality, so instead of encouraging them and working with them to reach a coherent, cooperative whole system, these other repositories were simply shunned. Now I have many packages from these "rogue" repositories on my machines, and this makes the online upgrade from one version of Fedora to the next a rather time consuming effort. Not impossible, but much more difficult than The other problem is that the Red Hat/extras repositories have not been designed with on online If Red Hat would do the following, it would be wonderful:
|
|
||||||||||||