Beginning to administer perl on Ubuntu

jjore on 2009-05-03T23:04:15

Inspired by some traffic on module-authors@ and similar, I'm trying to use cpan2dist to create debian packages of CPAN modules, with easy and no fuss.

It's... a slog. Apparently CPANPLUS::Dist::Deb assumes you'd only ever want to use the system perl. I'm working through the issues but it's an unhappy place to be right now. I figure I'm a pile more hours out from being able to use this. :-( Don't want to spend more of my weekend on this.

BTW, is nifty to give the right 90 seconds worth of info that the manual doesn't.


be more specific

hdp on 2009-05-04T00:41:51

What do you mean, it "assumes you'd only ever want to use the system perl"? what behavior is it displaying that you don't want?

I don't see any new bugs in the queue from you, and as a problem report, this post is pretty uninformative. Should I assume you don't actually want to get help, just to vent?

Re: be more specific

hdp on 2009-05-04T01:40:39

I got annoyed by your non-bug report enough to look at it myself and find that it pretty obviously doesn't work with anything but /usr/bin/perl.

http://github.com/hdp/CPANPLUS-Dist-Deb/tree/master

See if that helps. It still won't handle installs that are under a different top-level directory than /usr very well, if at all, and some of the directories are a bit dodgy (/usr/share seems hardcoded), but it will actually build a deb with a different perl.

Re: be more specific

jjore on 2009-05-04T02:33:26

I have a series of patches I wrote to be able to create a .deb for CPANPLUS::Dist::Deb starting with a "stock" mod_perl enabled but non-threading perl-5.10.0 in a non-standard location (-Dprefix=/opt/perl-5.10.0 -DDEBUGGING=-g -Duseshrplib).

I merely blogged my frustration. The patches worked right out of the gate but now after upgrading part of CPANPLUS they don't work anymore.

Things I had to fix:

  • Call {Build,Makefile}.PL with the right perl instead of just /usr/bin/perl
  • Re-introduce the Replaces: logic when not using the stock Debian perl package
  • Debs depend on the system perl only if they're actually built against it
  • Run tests in a predictable order for easier debugging. Stock is to use some hash order
  • Use $Config{man3ext}, not 3pm
  • Install to $Config{prefix}, not /usr
  • Clean poisonous PERL* entries from %ENV
  • Use $^X, not /usr/bin/perl

None of it's a killer but I thought this already "Worked." Actually, I have several problems now. Do I push this to github to make it easy to share the patches even though they're not "ready" yet? What upgrade just broke the patches so the tests no longer pass? What to do about distributions which clobber each other's files like ExtUtils::MakeMaker and ExtUtils::Install?

If you want the patches "early," I copied their current state out to http://diotalevi.isa-geek.net/user/josh/090503/