This is the mail archive of the
mailing list for the Cygwin project.
Re: Stop turning CPAN modules into Cygwin packages
2007/12/12, Igor Peshansky <email@example.com>:
> On Wed, 12 Dec 2007, Jerry D. Hedden wrote:
> > Eric Blake wrote:
> > > A new package, perl-Error-0.17010-1, is now available for use.
> > >
> > > NEWS:
> > > =====
> > > This is a new package, providing the Error module for perl.
> > What is the point of making this a Cygwin package? There
> > are no Cygwin specific changes, and it it can be installed
> > directly from CPAN using:
> > cpan -i Error
I hope Eric put it into vendor_perl, so there will no conflict when
doing cpan -i Error
Otherwise it's ok for me if some minor perl module is an external
> As I understand it, this is a prerequisite for "git", which is a Cygwin
> In fact, that's the only reason I see for making CPAN modules into Cygwin
> packages (the Cygwin-specific patches, as you've said yourself, should
> eventually be sent upstream).
> > This seems to be becoming a trend. So far there are 8 CPAN
> > modules that have been made into Cygwin packages. Only 3
> > have Cygwin specific changes that would justify them being
> > made into package:
> > perl-Locale-gettext
> > perl-Tk
> > perl-libwin32
The cygwin libwin32 is now in sync with CPAN. Just the updated perl
package 5.8.8-5 is missing to be in sync with the latest libwin32,
which I packaged last month, but found
an error while testing.
> > The other 5 have no Cygwin specific changes:
> > perl-Error
> > perl-ExtUtils-Depends
> > perl-ExtUtils-PkgConfig
> > perl-Module-Build
> > perl-Win32-GUI
> FWIW, some of these modules might be worth packaging as part of the Cygwin
> Perl package (in vendor_perl), rather than as separate packages.
>From what I know by hard, Module::Build will be included in the next perl CORE
package, and the others could go into vendor. Besides libwin32 and
Win32::GUI of course.
Win32::GUI is a special case.
I just wanted to have that in as counterargument that only ActiveState perl is
good for doing Win32 specific development, and it is the 2nd most important
Win32 package besides libwin32.
Both now build OOTB in cygwin, so there's no dying need to have it as
cygwin package, but having it there does no harm, as long there are not
50 other packages coming.
> > This seems like a bad practice.
> Ok, let's take these points one-by-one.
> > It adds a maintenance burden on the Cygwin system (because the packages
> > will need to be updated when the modules are updated),
> Yes, but that's the choice of the volunteer maintainer. Eric packaged
> these because he maintains git, and it was the easiest way for him to make
> sure the target system contained the required modules. So, in effect, it
> *eased* his maintenance burden.
> > they needlessly take up storage on the Cygwin servers,
> Storage is cheap, and nobody has complained yet.
> > and turning them into Cygwin packages adds no value over obtaining the
> > modules directly from CPAN.
> Sure it does. For one, they could be added as dependencies of other
> packages (as you yourself agreed), and also they can be included on
> installation CDs, etc, which could be installed without internet
> connection (which is one reason to not request CPAN install in a
> postinstall script).
> > Just because you can turn a CPAN module into a Cygwin
> > package doesn't mean that you should unless there are Cygwin
> > specific changes that need to be made. Even then, a better
> > approach is to send the appropriate patches to the module's
> > maintainer so that they can be integrated into the code and
> > uploaded to CPAN.
> BTW, this problem must have been encountered (and, hopefully, solved) by
> other distros. How does the Debian git package handle this? I seem to
> recall that at least Red Hat Linux at some point had packages for some
> CPAN modules...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html