A short rant on Ubuntu and dpkg: fuck you, dpkg
A long long time ago, in a gal… in an older computer, I had Fedora. RPM — the packaging system in Fedora — was amazing in several aspects. And the aspect that continually amazed me was the transactionality of software installs: a set of packages either gets installed, or it doesn’t. No halfway installs, no broken shit. Ever.
Fast-forward to my contemporary Kubuntu system. I just installed (using dpkg -i) a series of packages, and dpkg happily unpacked them all on my filesystem, only to nonchalantly tell me — when the files were already replaced on my (now very broken) computer — that it could not configure these packages, because the version of my C library is too old.
With the new files are already on my system! A tad too late to blow up on my face, isn’t it? Now I have a badly broken system, and I can’t back out without resorting to manually downloading and installing old packages.
Question to the dpkg developers: If the version of my C library is too fucking old — and dpkg knows this fact — why the fuck does dpkg proceed with file installation, only to barf in the middle of the installation process, leaving me with a broken computer? If the dependencies don’t fucking fit, don’t fucking let me install the packages in the first place!
It’s not like transactional package installation is rocket science to get right, is it? Otherwise, how did the RPM guys figure this out so well?
In b4 “dpkg is not like RPM” comments:
- Software installation transactionality is an elementary requirement of contemporary systems, so get your damn act together and make dpkg like RPM with regards to this issue.
- Even better: ask yourselves the following question: in what universe is this dpkg behavior (namely, enabling users to badly break their systems) a good thing?
And, please, let me rant some more, this time on the topic of package dependencies. Why does a simple 100 KB program from Hardy require me to upgrade my system C library (hence, my entire operating system) to Hardy? I thought glibc hadn’t changed in years! I hardly doubt that 100 KB program would have any trouble running if I unpacked the binary directly! So why does the package builder automatically require the latest version of the library — forcing me to download gigabytes of packages — when an old one would work just as well?
I’m a sysadmin, for fuck’s sake, I want my computer to be easily manageable, not harder to manage. What are you waiting for?
January 4th, 2008 at 18:39
good rant (really)
January 4th, 2008 at 18:44
That seems a problem of the packager of that app, no the dpkg system itself. If you had run dpkg with –no-force-depends-version, you didn’t need to update glibc. Maybe if you read $man dpkg you can find how to fix the system now. Good luck.
January 4th, 2008 at 19:15
FreeBSD’s ports system is a far cry above any similar package system. It’s got the “transactional integrity” of RPMs, the breadth of apt, and is very stable. Check it out, if you have a chance.
January 4th, 2008 at 19:25
Amen brother….amen…
January 4th, 2008 at 21:43
I ran Kubuntu since 5.10. I liked Kubuntu but occasionally had issues such as these or needed to upgrade apps from third party repositories to get rid of bugs. Some bugs have been in Kubuntu for four releases? I now use Sidux on my machine & on friends machines I look after! Sidux is Debian Sid (Kubuntu is Sid based) with scripts to upgrade & maintain the system. The bugs I had in Kubuntu are now gone & I no longer need to upgrade apps from third party repositories because Sid has them in their repositories “hot off the presses”!
January 4th, 2008 at 21:56
Dude it’s free. I’m a newbie convert from w1n70w5. What ever i don’t know i do a search hi & low to look for a fix, w1n’ or l1n’ .If you are a sysadmin, you must suck at it if you can’t fix an OS or even take the time to type g-o-o-g-l-e and do a search. Why are you even under digg/lin’x, you should b on michelsoftt putting your rant’s & rave’s.
January 5th, 2008 at 0:27
Liam is right.
But pacman is also good. I use Arch Linux for three months and nothing can give me more satisfaction.
Why did you install the packages the dpkg way? Fire up synaptic/adept and you have everything you need.
January 5th, 2008 at 3:06
Why dont you try a rpm based system? Mandriva and PCLinux are both use KDE with the added benefit of a great control center. Both are very user friendly and stable. Personally I use PCLinux as I found it to be just a little smoother than Mandriva.
January 5th, 2008 at 4:21
OK. Answers. I don’t use an RPM-based system because there are more packages for Kubuntu, they are usually more updated and I like how Kubuntu behaves in general.
Smack: so what if it’s free? Does this mean I have to tolerate this catastrophe? Am I not free to expose the problems within the system? For your information, I fixed the problem manually in ten minutes — I didn’t even have to Google for a solution — but I would have liked NOT HAVING TO SPEND that time, thank you very much.
twilight: I couldn’t use apt-get because I wanted to install packages from Hardy, because the packages I wanted were an upgrade to a program that has not been updated in Gutsy. To do what you suggested, I would have had to alter apt repository configuration, and then apt-get would have prompted me to download gigabytes of data. I wanted to install two megs’ worth of packages. Trust me, I did what I did for a very, very good reason — and I expected the system to alert me if what I was doing was gonna break it — RPM always did.
January 5th, 2008 at 4:45
Well, for next time you want to install package from another version try this: apt pinnimg… you can use multipile repositories and tell apt which version you want, without forcing a whole upgrade. Really you try it. I mix feisty and gutsy like this.
January 5th, 2008 at 6:13
Pinning sounds interesting, but it wouldn’t help because libpulse0 0.9.8 the-package -WANTS- the latest libc, despite libpulse0 0.9.8 the-binary working just fine with the old one.
January 5th, 2008 at 12:24
You should definitley try apt pinning, however as someone mentioned here before this is just a bad packaging. You should write to maintainer of the package, and not blame dpkg. However, I do agree with you criticism. It’d be smarter to check and the deploy the package, instead of the current process.
January 5th, 2008 at 17:16
Actually, pinning wouldn’t solve one of the problems, while better packaging wouldn’t solve the other. These are two separate dpkg issues melded in a single post.
January 6th, 2008 at 7:53
Why does a simple 100 KB program from Hardy require me to upgrade my system C library (hence, my entire operating system) to Hardy?
AHAHAHAHAAAAAHAHHAAAAA nice
January 6th, 2008 at 15:21
Man.. I have had this same kind of problem before. The reason is: Hardy is UNDER DEVELOPMENT! It may fuck up your computer any minute. Most likely is not even a dpkg problem, but a package (read the “.deb” fiule you installed) problem.
If you want to play with an Alpha do so, but not under a machine you use everyday. It’s just like fire… You may get burned.
Hope you find a way to fix this…
R.
January 6th, 2008 at 15:27
Rubén, you’re wrong. I didn’t install Hardy. Please reread because your entire argument is based on a misguided premise and I’m too lazy to restate what’s already stated in the article.
FYI: I fixed it in five minutes, thank God I had some PA packages that I built myself. Then I built the Hardy packages from source for my machine. That also let me install the latest PA without the libc issue.
January 7th, 2008 at 14:48
So, let me get this straight. You tried to install a package from a development version of the distro on a stable version of the distro and expect it to work? Yes, it is possible that glibc API didn’t change significantly, but you cannot rely on it. New versions of glibc will introduce new or changed APIs and a program compiled against a newer version of glibc cannot be expected to work on an older version. Hence the dependency. You are always welcome to download the source package and compile it for your current system. Especially if the package in question is a shared library (think other packages compiled against an older version of it that stop working with the newer version).
Yes, dpkg shouldn’t have done that. But I don’t think replaced libpulse would break your system so bad. I am pretty sure libpulse is required for booting and basic command line operations or even starting X and KDE.
On the other hand I am happily running Fedora 8 with some Fedora 9 (development) packages installed without any problems
January 7th, 2008 at 15:09
Yes, I expected it to work. Cos’, you know, the libraries may have gone new, but they haven’t gone up a MACRO version up, so they should be binary compatible with the old libraries. So, I expected it to work just fine, ESPECIALLY AFTER I STARTED THE INSTALL, AND THE PACKAGES INSTALLED SUCCESSFULLY… but then the configuration stage BARFED ON ME.
Hey, RPM packages also suffer from the same overzealous version bumping (which is wrong by the way). But at least I expected dpkg to stop me from installing packages that would lead to a broken system.
Yeah, blah blah, source compiling, that’s what I ended up doing. Blah blah, WHAT THE FUCK, ARE WE IN 1981 OR 2007? Why haven’t we solved this problem by now?
Yeah, the reason we haven’t solved this problem is because it’s easier to let the deb build process identify the dependencies in an overzealous, “let’s play it safe” way that requires the latest and greatest libraries. And because the dpkg maintainers still haven’t got around to getting their heads out of their asses and doing proper dependency checking PREVIOUS to package installation.
Just my humble assessment.
January 8th, 2008 at 13:05
Well, as you say, the solution to this problem is to do dependencies by hand. Considering the sheer number of Debian/Ubuntu supported packages that is just not feasible. Rebuilding dpkgs from source is a fairly painless and easy process. You wanted to mix and match packages from different versions of distro, so you should expect to get your hands a little dirty. There is always an alternative way, of posting a request to the backports maintainence and waiting for them to package a backport.
January 8th, 2008 at 13:40
No, I should not expect to get my hands a little dirty, it should just work. What’s wrong with by-hand dependencies for those dependencies where it makes sense? Sure, it’s LOTS of work, but it’s a worthwhile cause.
Plus, dpkg should not have let me install anything that breaks my system because of unmet dependencies.
January 12th, 2008 at 14:08
Why is glibc even in the dependency list anyway? You pretty much can’t run anything without a C library, just like you can’t run anything without a kernel. Debs should not be listing such things as dependencies anyway, except in very very special circumstances. The fact that you can even run dpkg in the first place should already guarantee a suitable version of glibc.
But yes, there is no excuse for needing to do extra fussiness because of a glibc dependency. I used to run Gentoo, so I would always be bit by ABI changes. Glibc doesn’t break things. I didn’t even have to recompile things when I switched from LinuxThreads to NPTL. The Ubuntu people really need to do some better package management.
April 13th, 2008 at 23:37
This is a case of an idiot packager not a dpkg problem. Also I find “I want my computer to be easily manageable” odd as I actually switched to Ubuntu from an RPM based distro and this was one of the the things I loved about it.