| |||||||||||||
Do we need this crap on LWN?Do we need this crap on LWN?Posted Feb 21, 2007 20:24 UTC (Wed) by mokki (subscriber, #33200)In reply to: Do we need this crap on LWN? by ofeeley Parent article: ESR's goodbye note
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).
(Log in to post comments)
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 (guest, #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.
|
|||||||||||||