Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ddick (5726)

  (email not shown publicly)

I'm based out of Melbourne, Australia. I attend the excellent meetings whenever i get the chance, which is not often enough.

Journal of ddick (5726)

Monday May 21, 2007
06:32 AM

complied perl in sarge - etch upgrade

[ #33320 ]
recently had a bit of a unexpected issue with perl daemons refusing to come back up after a debian sarge -> etch upgrade. It seems that any compiled modules are stuffed after the upgrade as the perl in etch has a completely different $Config{archname} than sarge. This resulted in a few interesting surprises. I'm sure i remember something somewhere talking about the reasons, but i can't remember where. I can't see it in the debian release notes, but i could just be blind. at any rate, i would hope no-one else needs to suffer through this issue.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • At some point, for large applications, it seems that just compiling your own application-specific Perl is the only real solution.

    BTW, what were the archnames changed from and to?
    • well, i gave a talk at a short time ago on building debian and rpm packages for perl applications, so agreed. The interesting thing is that all the other changes that debian made (lintian had extra error checking added, a few modules needed to be upgraded) meant that a etch package should have been installable on sarge. Now this is not the case.

      the archname was "i386-linux-thread-multi" and is now "i486-linux-gnu-thread-multi". call me paranoid, but i sense a politics vs practical battle wa

      • On the plus side, this also means they can, nay, HAVE to clean out the backcompatible @INC bloat :)