BlaBlubbBlog

This is a lesson in how to very subtly break your Ubuntu. I recently removed the Ubuntu TeX installation in favour of having a fresh texlive installation ins /usr/local. That is fairly easy to do and I am quite happy with it. However, when I applied the Ubuntu updates last Monday, two packages (gcc-4.2-doc and gfortran-4.2-doc) failed. I tried to remove and then reinstall them, but that didn't work, well, the removing didn't work in the first place, always a error that a

subprocess returned an error code (1).

Well, I didn't have the time or the inclination to start digging for the error there, the compiler docs are nothing I need regularly, certainly not for gfortran anyways. But then I wanted to install a couple of new packages today and that didn't work, because the messed up gcc-4.2-doc was hanging there in the process and there was no way to deselect it or ignore it.

So I started to look for the problem. You can find a few "don't know what that does, but it fixed it for me" gems out there of people hitting similar problems, albeit for different packages. The problem is actually in install-info, which fails with

install-info: No dir file specified; try --help for more information.

but, well, this gets called somehow in the process of the package management. And this is definitely nothing I want to understand.

At least I finally found the hint to edit the /var/lib/dpkg/info/[brokenpackage].{prerm,postinst} scripts to not call install-info to apply the updates without errors. After looking a bit more, I came across the interesting finding, that the install-info called in the packaging stage is not the install-info that is expected. In fact, the texlive installation put a new install-info in /usr/local/bin, which got executed instead of the one in /usr/sbin. Renaming the faulty one for a moment also solved the problems.

This is nasty. Really nasty. Now I need to check again what I did to the paths.