Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Updating Config.pm

by morgon (Deacon)
on Feb 23, 2013 at 19:27 UTC ( #1020332=perlquestion: print w/ replies, xml ) Need Help??
morgon has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

recently I had some troubles Installing Glib on Debian and after some digging the root-cause of my problems seemed to be a Config.pm that did not properly reflect the system anymore.

It turned out that the "libpth"-entry in Config.pm contained "/usr/lib64" (a directory that does not exist on the system), but not "/usr/lib/x86_64-linux-gnu" (this entry controls which directories ExtUtils::Liblist searches).

I have no idea how Config.pm and the system-state diverged (I assume the system was updated but not the perl) but I have anually updated Config.pm and everything works fine so far.

My questions would be: Is manually updating Config.pm an acceptable risk or do I run the dager of some problems further down the road?

And are the any tools for bringing back Config.pm to properly reflect a changed system?

Many thanks!

Comment on Updating Config.pm
Re: Updating Config.pm (not)
by Anonymous Monk on Feb 23, 2013 at 20:58 UTC

    My questions would be: Is manually updating Config.pm an acceptable risk or do I run the dager of some problems further down the road?

    Depends on how careful you are :) I think it's busywork

    If $PATH changed, would you edit Config.pm? python's config? php's config? rubys config?

    export LIBRARY_PATH=...

    export CPATH=...

Re: Updating Config.pm
by Intrepid (Deacon) on Feb 27, 2013 at 13:05 UTC

    morgon wrote (the quotations may be slightly adjusted to add my emphasis or correct typos or produce clear formatting):

    And are there any tools for bringing back Config.pm to properly reflect a changed system?

    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).

    My questions would be: Is manually updating Config.pm an acceptable risk or do I run the danger of some problems further down the road?

    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.

    recently I had some troubles Installing Glib on Debian and after some digging the root-cause of my problems seemed to be a Config.pm that did not properly reflect the system anymore.

    I have no idea how Config.pm and the system-state diverged (I assume the system was updated but not the perl) but I have manually updated Config.pm and everything works fine so far.

    There are a lot of implications that led to confusion for me in what you've written. In the top posting you stated:

    I am having troubles installing Glib for a self-compiled perl on a Debian-system.

    In the referenced followup message you have stated that:

    As far as perl is concerned the difference between the two machines is that one is 5.14.1 compiled from the source-tarball and the other is 5.16.2 installed via perlbrew.

    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).

    It turned out that the "libpth"-entry in Config.pm contained "/usr/lib64" (a directory that does not exist on the system), but not "/usr/lib/x86_64-linux-gnu" (this entry controls which directories ExtUtils::Liblist searches).

    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.

      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.

      Not really. The problem in each case is simple %ENV $path management.

      What the vendors do is save you precious compilation time, but when they don't provide binaries of a library, you have to compile it yourself

        You've clearly missed the notice on Intrepid's Home Node.

        I don't see posts by Anonymous Monk beginning at 6:30pm on 7 Dec 2005, by using CSS to override display settings. The texts of postings of any nature by any non-existing (Anonymous) Monk are invisible for me.

        Anonymous postings are Exception #2 to BrowserUK's Principle of Dispassionate Objectivism (“Examine what is said, not who speaks”).

        I allow "root" to keep informing me that there are reply-postings by Anonymous Monk (because there is no way to selectively switch off such notices for the that pseudouser alone); but I can and will ignore his notices; and I can and will skip the postings by Anonymous Monk as they come up in discussions.

        About that, people have claimed that there are justifiable reasons for some persons to post anonymously to perlmonks. On generous reflection, I have found none of the reasons suggested sufficiently compelling to change my belief that overall, anonymous posting subtracts from the value of the site.

        Why don't you tell us why you won't post as an identifiable individual, Anonymous Monk? Just explain it in plain honest words so we can get a picture.

        Just for the curious: Exception #1 is implied by BrowserUK's other Principle: “... Questioning authority.” It is justified, and important, to look harder for the self-serving motivation lurking in the word of those in positions of authority. To scrutinize them with a probing gaze more intense than is used on those not operating under the mantle of authority.

        Also, you are quite mistaken in your response to my point. Not only is it mere contradiction (as contrasted with informed disagreement) but my point was missed entirely: that the configuration problems (experienced by the OP) demonstrate that it is not trivial to get perl Configured correctly.

        I wrote:

        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

        You said:

        What the vendors do is save you precious compilation time

        ...which is hilariously atavistic in the light of the sun that rose today and will rise tomorrow. On what patch of earth is a user so constrained by her hardware that compilation time is "precious?" Most of our systems are so vastly over-powered and competent now that we could have them do compilation as a background task 24 hours a day and hardly make a dent in our ordinary system activities like watching a YouTube or listening to music.

        You also wrote:

        but when they don't provide binaries of a library, you have to compile it yourself

        If my words are misintepreted as saying anything contrary to that, then it is just that: a misinterpretation. Modules are another matter entirely. If the core perl installation is installed properly from the starting point of having been correctly Configured and built, installing modules ("binaries of a library" - huh?) is generally painlessly easy.

        BrowserUK has gifted us with another gem of Wisdom that goes like this: “In the absence of evidence, opinion is indistinguishable from prejudice.”. I see only opinions (and not very clearly expressed ones, at that) in your posts. There is no evidance that your statements represent efficacious (workable) or correct (perl-savvy, insightful, well-informed) knowledge. There's no evidence seen that your advice allowed the OP in this instance to solve his problems. In particular, this statement is "indistinguishable from prejudice":

        The problem in each case is simple %ENV $path management

        Rebuttal: In no way does manipulation of the $PATH cover all problems of perl configuration, and it definitely has nothing to do with any of the entries mentioned in this parent discussion (that pertain to where system headers and libraries can be found) that are written in Config.pm. There's my "opinion" without "evidence" (except that people who know the insides of what is under discussion know that this is correct without having to be shown, just as they know you are incorrect).

        Hope you enjoyed the moment in the light of my gaze, Anonymous Monk. The moment will not recur.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1020332]
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (8)
As of 2014-07-22 22:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (130 votes), past polls