Upgrade icu-4.6 to icu-4.8 - how to find all dependencies?

G

Goose997

Hi

I managed to break one or two ports by doing this upgrade. How do find all ports that I have installed that depend on this installation?

Thanks
Malan
 
pkg_info(1) with -R flag

example
Code: 
$ pkg_info -R icu-4.6.1                                                                  
Information for icu-4.6.1:

Required by:
boost-libs-1.45.0_1
cclive-0.7.4.1
webkit-gtk2-1.2.7_1
libopenraw-0.0.8_3
gegl-0.1.6_1
gimp-app-2.6.11_3,1
gimp-gutenprint-5.2.4_2
gimp-2.6.11,2
libreoffice-3.3.3
 
hi

Thanks, that works. In my desperation I did a portupgrade:
Code: 
portupgrade -fr devel/icu

which did the trick.

regards
Malan
 
Goose997 said:
hi

Thanks, that works. In my desperation I did a portupgrade:
Code: 
portupgrade -fr devel/icu

which did the trick.

regards
Malan
Click to expand...
I doubt ICU upgrade only involves those packages. ICU broken my system too and to fix it I had to do the same u did, takin hours :-(

This is the reason becouse I wont upgrade ICU in other production system.

The broken system is a backup server I use for connectivity and it need to be always up and - after damn ICU upgrade - I had it half service for like 5 days to fix all the problems.

BTW it was correctly write in the UPDATING files the need to recompile all the packages after ICU update. Then I found sometimes this is a conservative statement in the UPDATING file becouse sometimes it is not really necessary.
 
You can build the new icu port, check its pkg-plist for *.so*files, (determining the new number probably, or check the work subdir for .PLIST_Flattened )
Code: 
 locate icu | grep so
, copy those ones found, that you have already, to /usr/local/lib/compat/, and leave them there for the five days or so during which one upgrades the ports if need be, removing them afterwards. (Similar workaround exist for not rebuilding at all, just running the ports you know you will use to see if they really do depend upon icu, if they do they will probably not start and complain, (( your .so files temporarily *not* in /compat/ so the fail will work...) IOW with an hour or so of workarounds, you can still maybe have a production system running if one is careful, reversing the workarounds later. (Logging locally on paper probably expedient. )
....
Sorry if I left something out in the synopsis... it could be twice as long to be clearer for one who is not practiced in inferring the context.
 
You must log in or register to reply here.
Back
Top