On Thu, Apr 01, 2010 at 12:39:27AM -0400, David Nicol wrote: > On Wed, Mar 31, 2010 at 7:43 AM, Ask Bjørn Hansen <a...@perl.org> wrote: > > The main point here is that we can't use 20 inodes per distribution. > > so don't. How much reengineering would be needed to keep CPAN in a > database instead of a file system?
Random thoughts... * If you squint a little you can view git as a database with excellent replication support. * cpanminus already supports installing from a git repo. * For backwards compatibility a simple perl web server could provide a classic CPAN http mirror 'view' over a git repo like gitpan. This cpan-git-server would create and serve up cached distro tarballs on demand. Someone could whip up one to work over gitpan as a proof of concept. * The need for widespread mirroring is less significant than it was in years past. (Also using git as the inter-mirror transport of source files means there'll be much less traffic between mirrors. Effectively only the diffs between releases.) * New approaches to replication, such as git, don't have to be supported by existing mirror providers. A new set of cpan-git-mirror providers could emerge. * Any cpan-git-mirror provider running a cpan-git-server could be included in the list of mirrors used by existing installers. * Over time the number of cpan-git-mirror's and cpan-git-server's could grow and the number of traditional CPAN ftp/rsync mirrors could fall. Tim.
