Front page | perl.perl6.language |
Postings from May 2009
Re: New CPAN
From: Mark Overmeer
May 29, 2009 05:43
Re: New CPAN
Message ID: 20090529124313.GK19855@moon.overmeer.net
* Daniel Carrera (email@example.com) [090529 11:42]:
> Timothy S. Nelson wrote:
>> While I've no objection to building the end-user software to
>> support multiple repositories, I know that there are certain segments
>> of the community who are very very keen to keep everything in the one
> After reading the Zen of Comprehensive Archive Networks (ZCAN), I think
> there is very good reason for retaining the current infrastructure with
> the current, large, set of mirrors. That is not to say that we can't
> upgrade the packages and metadata.
It also says:
"Another important credo is: Avoid bottlenecks and interdependencies.
Decentralize. Create and encourage alternatives."
When reading the ZCAN, be very aware that it discusses CPAN. As users of
CPAN, we all know that it works (for the moment). But that should never
be a reason the think outside that box of daily practice! When making a
step in development, first figure out which components of CPAN are really
valuable, which are outdated, and which are missing. Then keep the good,
salvage the outdated and fill-in the missing.
Just to give you something to think of: with the current speed of
networks and price of hardware, you do not need a huge network of
daily synchronizing mirrors but a sufficiently large network of very
up-to-date mirrors. Preferrably smart mirrors, which can answer
(Ajax-like) some simple questions about distributions, such that you
do not have to download the immensely growing 02packages.details files
Ftp-mirror sync trees. If you add subtrees on your disk which contain
different archives or targets, then these will get mirrored as well.
> "CPAN shall not piggyback another language" -- from ZCAN.
> Judging from the ZCAN page, I don't expect that uploading Ruby modules
> to CPAN will go well, even if that module can be compiled to Parrot. The
> ZCAN page gave good reasons for this.
Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are
unrelated sets of data. The only relation is the people who use it.
Mark Overmeer MSc MARKOV Solutions