Dependency Hell.

[swestrup]

Once again I find myself trapped in dependency hell. There was a security alert on Apache with a recommended upgrade, so I did that. It required an upgrade to the latest management tools (written in perl). That required a new perl. The new perl doesn't have threads. My web application uses perl and threads.

So, download the source rpm for that perl version. It doesn't compile with threads turned on.
So, download the very latest version of perl for my distro (mandriva) and compile THAT.

It does compile with threads.

Go to install it, and it tells me that I will have to uninstall both the apache test harness and mod_perl. Luckily I'm not using either of them, so I install.

It breaks the installer (urpmi) which is written in perl...

I download the rpm of urpmi which goes with the version of perl I just installed.

It needs a new version of RPM.

I download the corresponding version of RPM. It has a billion unresolved dependencies.

So, I download the source for the RPM.

The build needs half a dozen devel libraries that I don't have installed. That would be simple to fix if my urpmi wasn't broken.

So, now I'm about to reinstall the old non-thread perl, so I can run urpmi, so I can satisfy the RPM dependencies to build a custom RPM .rpm so I can install it.

Who knows what that will break.

And I was just reading an article about how Mandriva had the best upgrade and dependency solving system of all the Linuxen.

AAARRRRGGGGHHHHH!

Comments

[tjernobyl.livejournal.com]

On our FreeBSD systems at work, we ended up compiling our perl+threads binaries statically and calling them explicitly in the scripts. I've found it easy to code for, but it doesn't seem to get much respect. FreeBSD threatened to drop Perl entirely from the base distribution over it, if I recall correctly...

[swestrup]

Yeah, I'll probably do something along those lines. Of course, to do so I'll need to figure out how rpmbuild works so I can get the dang thing to build what I want...