Rtfem

title: RTFEM date: 2004-09-25 16:12:38

Okay, this is a tangled tale...

I've got an old install of FreeBSD I decided to bring up to date. Being the funky sort, I decided to do a portupgrade and keep the OS the same. (Security fixins [fixins! yeah!] have been applied, so I'm not too worried about doing make world.) And of course, desktop of the elder gods (...) Gnome was installed -- 2.4. Whee! Dive right in, right? That's why the gods gave us port-upgrade! Wrong. Got this error:

/usr/bin/ld: warning: libintl.so.4, needed by /usr/X11R6/lib/libgconf-2.so, may conflict with libintl.so.6
/usr/bin/ld: warning: libgmodule-2.0.so.200, needed by /usr/X11R6/lib/libgconf-2.so, may conflict with libgmodule-2.0.so.400
/usr/bin/ld: warning: libgobject-2.0.so.200, needed by /usr/X11R6/lib/libgconf-2.so, may conflict with libgobject-2.0.so.400
/usr/bin/ld: warning: libgthread-2.0.so.200, needed by /usr/X11R6/lib/libgconf-2.so, may conflict with libgthread-2.0.so.400
/usr/bin/ld: warning: libglib-2.0.so.200, needed by /usr/X11R6/lib/libgconf-2.so, may conflict with libglib-2.0.so.400
../../libgnomevfs/.libs/libgnomevfs-2.so: undefined reference to `bonobo_poa_get_threaded'
gmake[3]: *** [test-vfolder] Error 1
gmake[3]: Leaving directory `/usr/ports/devel/gnomevfs2/work/gnome-vfs-2.6.1.1/modules/vfolder'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/ports/devel/gnomevfs2/work/gnome-vfs-2.6.1.1/modules'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/devel/gnomevfs2/work/gnome-vfs-2.6.1.1'
gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/devel/gnomevfs2.

which lead me to this page, which (sadly) wasn't much help. I figured out that the problem was conflicting versions of glib, but WTF to do about that? After much searching, I began to remember faintly something about a FreeBSD Gnome upgrade page. Sure enough, this was the one I was thinking about. And look at this:

It is not possible to upgrade from GNOME 2.4 to GNOME 2.6 by simply running portupgrade(1). There are new dependencies, and ports will build out-of-order, eventually causing the build to fail. Additionally, GTK+-2 cannot install when there are input methods installed which were linked against older GTK+-2 versions. To work around these problems, and to provide an update mechanism as simple as portupgrade(1), the FreeBSD GNOME team has produced a comprehensive upgrade script. The script can be downloaded from: http://www.FreeBSD.org/gnome/gnome_upgrade.sh Simply download that script, and save it to disk.

Sigh. So I read the bit about how running the script after doing The Thing You Shouldn't Do would probably not cause problems, and decided to plunge ahead. But things ended badly when it came time to upgrade Scrollkeeper: [configure does some stuff...] checking for DocBook XML DTD... configure: error: not found. Make sure you have the DocBook DTD installed and ensure that it is registered in /usr/local/share/xml/catalog.

Wha'? Being me, I ignored the bit about the file it was looking for and dove right into the configure script. By the time I came out the other side, I figured out that it was unable to find /usr/local/share/xml/catalog. Then I re-read the error message. Well, fuck. After some digging around, I found out that this file was provided by sdocbook-xml on the old system -- version 4.1.2.5. The version I was trying to upgrade to ws 4.1.2.5_2. Shouldn't be that big a difference...but it is. The Makefile for the older port has this at the end: post-install: ${MKCATALOG} -q -c ${CATALOG} install sdocbook catalog But the newer port's Makefile has this: post-install: ${XMLCATMGR} -sc ${CATALOG_PORTS_SGML} add CATALOG ${SDOCBOOKDIR}/catalog ${XMLCATMGR} -c ${CATALOG_PORTS_XML} add nextCatalog ${SDOCBOOKDIR}/catalog.xml which, natch, doesn't make the file that scrollkeeper's configure script is looking for. Freshports.org has this note on its sdocbook-xml page:

Switch to using xmlcatmgr from mkcatalog. # Maintainers, please let me know if I break something in your port. Submitted by: hrs

After that is listed a crapload of PRs that the change fixes, or at least addresses. What to do? The thing that every sysadmin does sooner or later: cheat. # ln -s /usr/local/share/xml/catalog.xml /usr/local/share/xml/catalog And bugger me senseless with an iPod if it doesn't work. Who said cheaters never prosper?