Maintaining a darkpan?

davehodg has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to build a darkpan to replicate the levels of modules we have on a certain live site. Backpan has been very good to me, providing the versions of modules rpm -qa tells me we've wrapped and installed there, so I have a mirror of all that using Schwern's mighty BackPAN::Index to find them.

My next step is to index that mirror tree so that cpanm can use the local mirror.

cpansite appears to put 02packages.details.txt.gz in global/ which cpanm doesn't expect.

Miyagawa pointed me at the "OrePAN" module which mostly works but occasionally indexes wrongly, for example, I have:

authors/id/M/MN/MNOONING/Net-Daemon/Net-Daemon-0.44.tar.gz

Which is puts in 02packages.details.txt.gz as:

Net::Daemon     0.44    N/Ne/Net-Daemon/Net-Daemon-0.44.tar.gz

I *could* cpanm Net::Daemon with the exact path to the .tar.gz but that's a little suboptimal.

So, does anyone maintain a darkpan and how do you do it?

TIA,

Comment on Maintaining a darkpan?

Replies are listed 'Best First'.
Re: Maintaining a darkpan? by moritz (Cardinal) on Mar 26, 2012 at 11:27 UTC
You could maintain a second mirror, this one by CPAN::Mini, and use CPAN::Mini::Inject to add more distributions. I haven't tried it, but from the SYNOPSIS it doesn't seem to be hard to use. Perl 6 - second systems done right	[reply]
Re: Maintaining a darkpan? by davido (Cardinal) on Mar 26, 2012 at 15:46 UTC
It sounds to me like you have a good use-case for Pinto. Jeffrey Thalhammer spoke to the Los Angeles Perl Mongers last week, presenting Pinto and giving some excellent examples of how to use it effectively. I expected to find his slides on the LA-PM website but they're not up yet. You might get in touch with him to request the slides. On CPAN he is thaljef and on Github, thaljef. Pinto can be integrated with a DarkPan repository, and it also can be placed under version control (git or svn depending on your preferences). It allows you to pin certain modules to a specific version number, while allowing others to be upgraded. It allows you to maintain local (darkpan) versions of modules, and other dependencies not included in your local repository will still be grabbed from CPAN. It seems very well thought out. I'm anxious to find the time to give it a try myself. Dave	[reply]
Re: Maintaining a darkpan? by Khen1950fx (Canon) on Mar 26, 2012 at 15:13 UTC
To maintain a darkpan, see CPANizing Behavior and Democritizing Publishing by chromatic. Remember, a true star can only shine in the darkness of the night.	[reply]
Re: Maintaining a darkpan? by JavaFan (Canon) on Mar 26, 2012 at 12:57 UTC
So, does anyone maintain a darkpan Yes, but not in the way you're looking at it. There's just too much overhead in mimicing CPAN, and it's just too focussed on Perl. Typically, I either use a version control system (git, CVS, home-brew) to replicate to various systems, or I've used a general package system (RPM + yum, puppet, cfengine, Solaris packages, and HP and AIX solutions whose details I've lost over time). Neither of them can be said to be "better"; different environments ask for different solutions. I just cannot imagine a situation where a CPAN lookalike would be the best solution.	[reply]
Re: Maintaining a darkpan? by davehodg (Acolyte) on Mar 30, 2012 at 19:52 UTC
This is my solution: http://www.davehodgkinson.com/blog/2012/03/maintaining-a-darkpan/ Hope it's useful!	[reply]