X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <6910a60712121732y28d1dccekddca0d14ad2b6f3a@mail.gmail.com>
Date: Wed, 12 Dec 2007 20:32:38 -0500
From: "Reini Urban" <rurban AT x-ray DOT at>
To: cygwin AT cygwin DOT com
Subject: Re: Stop turning CPAN modules into Cygwin packages
Cc: "Jerry D. Hedden" <jdhedden AT cpan DOT org>
In-Reply-To: <Pine.GSO.4.63.0712121036130.24563@access1.cims.nyu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1ff86f510712120704w5f175db9md89d05d936d535ed AT mail DOT gmail DOT com> 	 <Pine DOT GSO DOT 4 DOT 63 DOT 0712121036130 DOT 24563 AT access1 DOT cims DOT nyu DOT edu>
X-Google-Sender-Auth: d06c90372606945a
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

2007/12/12, Igor Peshansky <pechtcha AT cs DOT nyu DOT edu>:
> 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
dependency.

> As I understand it, this is a prerequisite for "git", which is a Cygwin
> package.
>
> 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.

Agreed.

> 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...
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/