Jos Chrispijn wrote:
Can someone explain why we have to run an update batch in order to have all Perl related programs running with this update? Wouldn't it be better to upgrade Perl and have all programs use it as it hadn't been updated at all?
You're talking about the update of lang/perl5.10 from perl-5.10.0 to perl-5.10.1 ? The reason you need to run perl-after-upgrade is because perl library modules are stored in directory trees which encode the perl version number. perl-after-upgrade basically moves installed modules from/usr/local/lib/perl5/site_perl/5.10.0
to
/usr/local/lib/perl5/site_perl/5.10.1
plus it fixes up all of the pkg-plists and various other places where
the directory path is embedded. Alternatively you could just re-install
every single perl module on the system, plus any other ports that depend
on perl, but that's going to be the majority of the software on your machine
and perl-after-upgrade is a lot quicker.
Even so, ports that embed a perl interpreter -- ie. that dynamically link
against libperl.so -- will need to be recompiled, to account for libperl.so
now being in a different location. There aren't too many of these:
net-mgmt/net-snmp and www/mod_perl{,2} are probably the most commonly
encountered. One of the functions of perl-after-upgrade is to tell you what
packages need to be rebuilt because of this.
Why isn't perl-after-upgrade run automatically? Two reasons. Firstly, the
ports system cannot itself distinguish what updates would require
perl-after-upgrade to be run: when updating, the mechanism is to delete the
old package and then install the new one as if de-novo. The newly installed
package has no information about what older version of itself it is replacing,
if any.
Secondly, you can't make perl-after-upgrade clever enough to deal with all
conceivable corner cases. Other than by enforcing particular usage rules
on how individual admins manage their perl installations -- a policy that
is manifestly *not the BSD way* -- this is unfeasible. Given that we hold that
it is in the gift of the individual admin to decide how to manage their systems,
there have to be stages somewhere that involve the admin making a concious
decision about what to do. Running perl-after-upgrade is one of those points.
Lastly, just to note that if the upgrade is across a significantly large change
in version number: eg from perl-5.8 to perl-5.10, then any dynamically loaded
compiled extension modules (see perlxs(1)) will have to be recompiled as the
ABI is not guaranteed to be kept the same in that case. Unfortunately,
distinguishing modules that use perlxs from pure perl modules is not something
the ports system is currently capable of, so the upgrade instructions there are
"rebuild everything that depends on perl".
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
