WARNING: devel/icu: recent update redners openldap-server and other ports unusable!

[Matthew Rezny]

> On Fri, Feb 07, 2014 at 10:54:45PM +0100, O. Hartmann wrote:
> > 
> > Today a couple of updates has been introduced, one of them was an
> > update of port devel/icu.
> > 
> > I the good manner/tradition of updating UPDATING, I expect a
> > warning/hint/advice a couple of days from now - when everybody has
> > already stepped into the mess.
> > 
> > On several boxes running 11.0-CURRENT and 9.2-STABLE, updating ports
> > including devel/icu renders many ports unusable due to a library
> > version bump in libicu.
> > 
> > After updating ports relying on devel/icu via
> > 
> > portmaster -r devel/icu
> > 
> > and the updating of port
> > 
> > net/openldap24-server
> > 
> > (which is openldap-sasl-server in my case), OpenLDAP doesn't start
> > anymore on all boxes affected by the update of devel/icu!
> > 
> > I always get the error
> > 
> > 52f5551f hdb_db_init: Initializing HDB database
> > 52f5551f olcDbDirectory: value #0: invalid path: Permission denied
> > 52f5551f config error processing olcDatabase={1}hdb,cn=config:
> > olcDbDirectory: value #0: invalid path: Permission denied 52f5551f
> > send_ldap_result: conn=-1 op=0 p=0 52f5551f slapd destroy: freeing
> > system resources. 52f5551f syncinfo_free: rid=001
> > 52f5551f slapd stopped.
> > 52f5551f connections_destroy: nothing to destroy.
> > /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd
> > 
> > 
> > This obscure 
> > 
> > olcDbDirectory: value #0: invalid path: Permission denied
> > 
> > is not obvious to me. The server ran minutes ago BEFORE the update,
> > the directories containing the DB5 databases have all the correct
> > ownership (ldap:ldap, I suspected first a misconfiguration as this
> > error seems typical for a misconfiguration of the ownership).
> > 
> > Does anyone see the same problem? And maybe please would put out
> > some notes in UPDATING within a considerable narrow timeframe
> > regarding devel/icu! It seems, FreeBSD's ports systems get more and
> > more messy.
> > 
> > oh
> 
> devel/icu has nothing to do with openldap, neither with one of
> openldap dependency.
> 
> Have you checked the full path to the said DB5 databases and not only
> the directory containing those files?
> 
> regards,
> Bapt

If glib is compiled with the collation fix, it links against icu, thus
any port which depends on glib also depends on icu. The update to
devel/icu has made quite a mess of one of my systems when it took me by
surprise yesterday as well. There are multiple stumbling blocks along
the way.

glib20 won't build if libiconv is installed from ports. Uninstalling
the libiconv port allows glib20 to build against iconv in base. There
is a PR with a not yet committed patch that should workaround this.

net/avahi-app can't properly upgrade. The port builds libavahi-glib.so
and then immediately tries to link against the lib of the same name
that is installed rather than the one that was just built. The installed
version of that library is linked against old icu which doesn't exist
so the link fails. Uninstalling avahi-app first forces the build to use
the library compiled against current icu. This is a bug in the port.

There was also a problem with hal, which was the tip of the iceburg I
hit, but I relieved myself of the dependency on hal before I realized I
had a much bigger problem and many ports to rebuild. I did not revisit
hal to see if it would build correct after glib was rebuilt against
icu, or if it too needed some extra step.

Without any entry in UPDATING, I was facing linking problems against
glib that didn't make any sense. Current version of glib was installed
and the missing symbols weren't even really from glib. It was only when
I finally ran pkg_libchk and saw the huge mess of things that wanted
libicu.so.50 that the picture finally became clear.

Looking at the history of both devel/icu and UPDATING, I see that for
the 4.6 and 4.8 updates there was an entry directing users to run
portmaster -r icu, but for 5.0 and 5.2 updates there is not entry, so
this is the second time there has been an icu bump without any advisory
in UPDATING. Please do not neglect this step up when updating ports.