Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Jan 2009 17:15:17 +0100
From:      Jan Henrik Sylvester <me@janh.de>
To:        Christoph Moench-Tegeder <cmt@burggraben.net>
Cc:        ports-list freebsd <freebsd-ports@freebsd.org>
Subject:   Re: Ports required to rebuild after upgrading Xorg to 7.4
Message-ID:  <497B3E95.8050506@janh.de>
References:  20090124141243.GB35469@reindeer.haidundneu23.net

next in thread | raw e-mail | index | archive | help
Christoph Moench-Tegeder wrote:
>> Did you run portupgrade -rf libxcb?
> 
> On a related note: I ran above command _before_ doing a full
> "portupgrade -a". A whole bunch of ports failed to upgrade because

A mixture of -rf and a -a upgrade is always problematic, unless you were 
up-to-date before the library in question got updated.

If you do -rf before -a, some of the dependencies might be updated too 
early, expecting other ports to have been updated before that are only 
due in the -a phase. For example, port X depending on libxcb might also 
depend on libYYY, which does not depend on libxcb but got upgraded in 
the meantime. Thus, the new X depends on the new libxcb, but on the old 
libYYY. It will not be upgraded again and you will probably run into 
trouble at some time later.

If you do -a before -rf, it might be possible that some dependency might 
not be working during the -a, since it will only be repaired during the 
-rf, but something depending on this working is already upgraded during 
the -a stage. This is far less likely to cause problems, especially 
since portupgrade puts old libraries in /usr/local/lib/compat/pkg/ and 
thus, usually nothing is really broken. Moreover, linking against a 
currently broken library of the same version is not a problem, since the 
fixed one will later have the same version and (probably) same symbols.

It should be possible to do "portupgrade -a -rf libxcb -rf libgcrypt", 
but this will result in all packages being rebuild as far as I 
understand the portupgrade manpage.

I do not know how portmaster solves this, since without saving the old 
shared libraries, any build dependency that is broken in step one can 
cause trouble in step two.

BTW: Doing -rf is usually a lot more compile(!) time consuming than 
necessary, since indirect dependencies of a port usually (but only 
usually) do not link against the library in question. If you (think you) 
know what you are doing, you can try to find the ports that actually 
link against an old library using 'libchk -v' (or pkg_libchk as 
mentioned above). For example, 121 of my packages are directly or 
indirectly  dependent on libxcb, but only 31 seem to actually link 
against it.

Cheers,
Jan Henrik



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497B3E95.8050506>