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>