Ports required to rebuild after upgrading Xorg to 7.4
Jan Henrik Sylvester
me at janh.de
Sat Jan 24 08:15:25 PST 2009
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
More information about the freebsd-ports
mailing list