HEADS UP: xorg upgrade plans

[Kris Kennaway]

On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote:

> >No, at a minimum I am not comfortable recommending its use until it
> >saves old shared libraries across updates (I sent you email about this
> >a while ago), which is a vital safety and robustness mechanism.
> 
> I am one of people that dislike this and it is not required to get build  
> function. ;-) I think this option should be disable by default, because  
> put stuff in lib/compat/pkg hides the problems. Also:

No, it is required when dealing with shared library bumps (which
happen about once a week).  Otherwise all of the installed ports using
the library break if the new library build fails.  Talk to Brooks
about how annoying this is with e.g. gettext.

> http://www.freebsd.org/gnome/docs/faq2.html#q2
> ==============================================
> [...]
> Prevent two versions of the same library.
> 
> A common source of build failures is the existence of multiple versions of  
> the same library. This can happen if you have two different versions of a  
> port installed, or can even happen through normal portupgrade use. You can  
> back up the libraries in /usr/local/lib/compat/pkg and remove them, and  
> then run portupgrade -u -rf pkg-config. This will force a rebuild of all  
> GNOME-related apps (and a fair number of other apps) without retaining old  
> versions of libraries in /usr/local/lib/compat/pkg.
> ==============================================

I dispute the correctness of this entry.  The old libraries in
lib/compat/pkg are not linked to directly by new builds.  The only
situation in which something might end up being linked to 2 versions
of the library is if it pulls in a library dependency from an existing
port that is still linked to the old library.  In this situation the
build would be broken with or without lib/compat/pkg (in the latter
case, you have an installed port linked to a library that is entirely
missing, so that port will be nonfunctional).

Kris