|We don't bite newbies here... much|
Re: Updating Config.pmby Intrepid (Deacon)
|on Feb 27, 2013 at 13:05 UTC||Need Help??|
morgon wrote (the quotations may be slightly adjusted to add my emphasis or correct typos or produce clear formatting):
I cannot say there are not. I can say that there are no well known tools for doing that, and historically speaking it hasn't been considered a problem (such a tool would have been dismissed as “a solution seeking a problem”). This is no longer true - that's why I write historically. These days, a larger percentage of Perl users are working with a perl installed and managed by a package management system provided by a vendor (probably a GNU/Linux distro team).
See the above. The first category of danger is precisely that implied by package management tools updating your perl installation. To my knowledge no such tool is designed to examine Perl's Config.pm for local changes, and therefor to forbear to silently overwrite it.
There are a lot of implications that led to confusion for me in what you've written. In the top posting you stated:
In the referenced followup message you have stated that:
From this description it is certain / obvious that neither perl is a vendor perl (provided by Debian). In this case, the apparent expectation that the perl Config.pm would “be kept in sync with the system” seems odd. It can only do so if perl is re-built and re-installed! How could it be otherwise? This is what building Perl is. It must be Configured for the system that it is running on.
If the problem system was the one with the perlbrew-created installation, then perlbrew is what you have to look at for defects / issues. If not, then your error must arise from incorrect self-administration (you did not build perl correctly / did not update the build-install after system changes).
Overall this group of postings makes a strong case for most Perl users to rely on vendor-provided package management teams and the work they do (especially at Debian). It makes a case for relying on them (and appreciating them), and using what they provide instead of cooking up your own Perl installation.