Greetings, As my upgrade also required the change to subversion, it's been quite a challenge. I've nearly sorted out all the loose ends. But have a real issue with the path change for Perl. Yes, I've read UPDATING. For the most part, I upgraded all the ports via portmaster(8). But apparently that doesn't get it. While Perl seems to work, I receive a few errors, and have nearly no access to the (info|man)pages. An example error: perlinfo Date::Manip::Offset Subroutine path redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 29. Subroutine canonical_path redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 33. Subroutine perl_version redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 42. Subroutine perl_arch redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 47. Subroutine builds_port redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 51. Subroutine builds_standalone redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 66. How do I best sort this all out. I _really_ miss the perl_after_upgrade script, that used to accompany this process. Thank you for all your time, and consideration. --chris
Hello Chris On 09.07.2013 11:18, Chris H wrote:> How do I best sort this all out. I _really_ miss the perl_after_upgrade script, that > used to accompany this process.I also had some challenges with this perl upgrade, but I used portupgrade. In the end I created a custom script based on the output from 'portupgrade -nrf perl' which did the following: #!/usr/local/bin/bash set -e portupgrade -f lang/perl5.12 portupgrade -f converters/p5-MIME-Base64 portupgrade -f devel/p5-Test-Harness portupgrade -f devel/p5-Locale-Maketext-Simple [...] This script does abort, when a single command fails, so you see what fails and you can fix it. Eventually you will need to check dependencies and rebuild one of the ports now, which is later in the script. When the failed port did build, then remove the already done ports from the script and restart it. At the end I also did check the folders in /usr/local/lib/perl5/ for left overs in the folders from the old perl version. I then used pkg_which to find out to which port the belongs and did also a portupgrade -f for this port too. In the end everything was fine, but it took a little more effort, as I had around 235 ports to rebuild. But as long as you stay with e.g. perl 5.12.x, it is easier then before with the perl_after_upgrade script for minor updates. The next big challenge then will be the upgrade to e.g. 5.14.x or 5.16.x. bye Fabian
On Tue, 09 Jul 2013 04:18:37 -0500, Chris H <bsd-lists at 1command.com> wrote:> How do I best sort this all out. I _really_ miss the perl_after_upgrade > script, that > used to accompany this process.I've had zero problems with upgrades to Perl, etc after I stopped compiling my packages in the host OS and started building the packages via poudriere and using pkgng (sysutils/pkg). pkg can detect when a perl upgrade is happening and is intelligent enough to reinstall all programs that require perl; poudriere is smart enough to rebuild and repackage them all. It's a match made in heaven and dead simple to use.
In article <op.wzyd6vkx34t2sn at markf.office.supranet.net>, feld at feld.me writes:>I've had zero problems with upgrades to Perl, etc after I stopped >compiling my packages in the host OS and started building the packages via >poudriere and using pkgng (sysutils/pkg). pkg can detect when a perl >upgrade is happening and is intelligent enough to reinstall all programs >that require perl; poudriere is smart enough to rebuild and repackage them >all. It's a match made in heaven and dead simple to use.This. -GAWollman