Date: Tue, 04 Feb 2003 12:56:40 -0500 From: Greg Troxel <gdt@ir.bbn.com> To: freebsd-ports@freebsd.org Subject: libintl.so.2/4, portupgrade and evolution breakage Message-ID: <20030204175640.6F5087C7@fnord.ir.bbn.com>
next in thread | raw e-mail | index | archive | help
[I'm just getting added to freebsd-ports, so please cc me on replies.
My apologies if this is redundant, but I didn't find anything when
googling to figure out my evolution problem.]
I am running 4.7-stable, more or less, on i386.
I have had evolution (ports/mail/evolution) and a lot of gnome
installed for a while. Some pieces were installed last summer. After
I got 4.7 CDs, I upgraded a lot of packages, but not all of them,
using portupgrade. Recently I upgraded to the latest RELENG_4
kernel/userland. After this, evolution was no longer able to fetch
mail, and was giving complaints about $HOME/evolution/local/Inbox/mbox
of the 'bad file descriptor' flavor, which made no sense. After
upgrading evolution to 1.2.1, the problem was unchanged.
Other programs seemed fine.
After much consternation, I noticed that many shared libraries in
/usr/X11R6/lib were linked to libintl.so.2, and some to libintl.so.4,
and some to both at once. This stems from the change from 2 to 4 that
happened between gettext 0.10 and 0.11 (I think). I kludged around thisn
by making libintl.so.2 a copy of .so.4 and got evolution to fetch
mail.
So, I removed and reinstalled or rebuilt all packages whose shlibs
were linked against libintl.so.2 and am now rebuilding evolution.
I have been uncomfortable with the 'upgrade just one package without
rebuilding the packages that depend on it' philosophy of portupgrade.
This is of course a terribly convenient mechanism, and the portupgrade
man page correctly states that this is fraught with peril. It might
be good to have a stronger warning, or require forcing, if a shared
library version number changes in a package being updated. While the
strategy of placing the old shlib in a compat directory works for
simple dependencies, it fails for A -> B -> G and A -> C -> G when G
changes if B is then upgraded and C is not, since A is linked to B and
C and ends up with, well, libintl.so.2 and libintl.so.4. (I mean
run-time dependencies here on shlibs, not build-time dependencies.)
Another observation is that because libintl.so is linked into so many
things, it seems that extreme effort is warranted to avoid changing
the major version (and making incompatible changes). I haven't looked
at the details of gettext, so perhaps there really was no other way.
But adding a new procedure with new arguments or semantics and keeping
the old one, while it might seem displeasing, may lead to greater
overall system reliability and backwards binary compatibility.
It would be cool if portupgrade kept a database of packages whose
dependencies have been update, perhaps with an option to update those
in topological-sort order. When upgrading a package, anything that
depends on it would get added, and a package would be deleted when
upgraded. This would enable one to see what packages are in a
dangerous state and clean up. An alternative would be to do this only
when upgrading a package containing a differing shlib major version.
It is interesting to compare ports with NetBSD pkgsrc. NetBSD has no
dangerous options like upgrade-in-place or install two copies of the
same package - 'make update' always rebuilds all the dependent
packages, and one can't install a new version of an already-installed
package. So there is a lot more rebuilding, but it seems that pkgsrc
is far less likely to get into the broken state I encountered. But,
upgrading png would be a real pain - enough that I mv'd the
+REQUIRED-BY file out of /var/db/pkg/png-1.2.4, updated it, and put it
back. I knew this was safe since the shlib version number didn't
change and it was just a security bugfix. So, NetBSD's system could
do with an automated way to do that and keep a list of 'unsafe'
packages whose dependencies had changed, and FreeBSD ports could
benefit from similar automated tracking.
Greg Troxel
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030204175640.6F5087C7>