This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: perl Bundle::Cygwin / perl-bundle-cygwin package

On Thu, Dec 22, 2005 at 01:51:02PM -0800, Yitzchak Scott-Thoennes wrote:
> On Thu, Dec 22, 2005 at 01:14:06PM -0600, Yaakov S (Cygwin Ports) wrote:
> > Hash: SHA1
> > 
> > Yitzchak Scott-Thoennes wrote:
> > > I'm working on creating a bundle of common Perl modules that build and
> > > pass all significant tests on cygwin.
> > > 
> > > I hope to have it accepted as a cygwin package.
> > 
> > I think it's preferable to make separate packages for each module.  My
> > reasoning:
> > 
> > 1) this is the precedent set by Linux distributions;
> > 2) bumping one module doesn't require rolling a whole bundle;
> > 3) separate modules minimizes unnecessary dependencies;
> > 4) I'm sure there's something else I'm forgetting.
> > 
> > IOW, I do NOT like this idea.
> > 
> > If, OTOH, I do believe that more perl modules should go into the distro,
> > without packaging the entire CPAN, certainly:
> > 
> > 1) modules which don't build OOTB (e.g. Tk, gtk2-perl bindings, etc.);
> > 2) modules which are prerequisites for other packages (e.g.
> > ExtUtils::PkgConfig, necessary for building gtk2-perl bindings).
> > 
> > The same would apply, of course, to python and ruby.  You'll see I
> > already have a large selection on Cygwin Ports, although not all of
> > those are candidates for the distro.
> Large distributions like POE or the DateTime:: modules should have
> packages of their own.  I was thinking of smaller modules that it
> really would make no sense to have one package per CPAN distribution
> for, particularly common dependencies of other modules.

To further explain, suppose we had a package of all the DateTime::
modules (which are broken up into many distributions, but I hope you
would agree would belong together).  They have a number of small
general purpose dependencies; putting those in the same package
doesn't make sense to me, nor does packaging each individually.

I would lump them all together, along with the few modules we don't
have packaged yet but that come bundled with ActivePerl (for
competitive purposes :) and maybe some of the modules that will be
bundled with perl in 5.10.

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]