Stop turning CPAN modules into Cygwin packages

Stop turning CPAN modules into Cygwin packages

[Jerry D. Hedden]

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

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 other 5 have no Cygwin specific changes:
    perl-Error
    perl-ExtUtils-Depends
    perl-ExtUtils-PkgConfig
    perl-Module-Build
    perl-Win32-GUI

This seems like a bad practice.  It adds a maintenance
burden on the Cygwin system (because the packages will need
to be updated when the modules are updated), they needlessly
take up storage on the Cygwin servers, and turning them into
Cygwin packages adds no value over obtaining the modules
directly from CPAN.

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.

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Brian Mathis]

On Dec 12, 2007 10:04 AM, Jerry D. Hedden <jdhedden@cpan.org> 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
>
> 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 other 5 have no Cygwin specific changes:
>     perl-Error
>     perl-ExtUtils-Depends
>     perl-ExtUtils-PkgConfig
>     perl-Module-Build
>     perl-Win32-GUI
>
> This seems like a bad practice.  It adds a maintenance
> burden on the Cygwin system (because the packages will need
> to be updated when the modules are updated), they needlessly
> take up storage on the Cygwin servers, and turning them into
> Cygwin packages adds no value over obtaining the modules
> directly from CPAN.
>
> 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.
>

Because when you package something using a distro's packaging system,
you can start to have other programs that depend on it install them
automatically using the package system.  Also, installing from CPAN,
while very easy to do, does not keep track or even know about a
distro's package management system.  So if you wanted to remove it
later, it is not easy to do, and you could easily run into problems
where you have installed one version from CPAN, then another package
requires that module, but because you installed via CPAN it doesn't
know that, and will then install an older version, overwriting your
CPAN-installed version.

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Jerry D. Hedden]

Eric Blake wrote:
> A new package, perl-Error-0.17010-1, is now available for use.

Jerry D. Hedden wrote:
> What is the point of making this a Cygwin package?

Brian Mathis wrote:
> Because when you package something using a distro's
> packaging system, you can start to have other programs
> that depend on it install them automatically using the
> package system.  Also, installing from CPAN, while very
> easy to do, does not keep track or even know about a
> distro's package management system.  So if you wanted to
> remove it later, it is not easy to do, and you could
> easily run into problems where you have installed one
> version from CPAN, then another package requires that
> module, but because you installed via CPAN it doesn't know
> that, and will then install an older version, overwriting
> your CPAN-installed version.

Okay.  I'll grant you the dependency point, and I can see
adding a CPAN module if a dependency is created.  So far,
the only dependency that exists is for 'help2man' - it needs
perl-Local-gettext.

What is the justification for these 5 modules?
    perl-Error
    perl-ExtUtils-Depends
    perl-ExtUtils-PkgConfig
    perl-Module-Build
    perl-Win32-GUI

These have no dependencies, and no Cygwin specific changes.
Therefore, there is no benefit to having them be Cygwin
packages over downloading them from CPAN.  In fact, it is a
disadvantage because newer versions will always be available
on CPAN long before updates are made to the corresponding
Cygwin packages.

Again, I stand by my point of not turning CPAN modules into
Cygwin packages unless it is necessary.

--
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/

RE: Stop turning CPAN modules into Cygwin packages

[Dave Korn]

On 12 December 2007 15:31, Jerry D. Hedden wrote:

> What is the justification for these 5 modules?
>     perl-Error

  "Required by git".
http://cygwin.com/ml/cygwin-apps/2007-12/msg00094.html

>     perl-ExtUtils-Depends
>     perl-ExtUtils-PkgConfig

 "buildtime-only requirement for the Perl GNOME bindings"
http://cygwin.com/ml/cygwin-apps/2006-02/msg00196.html
http://cygwin.com/ml/cygwin-apps/2006-02/msg00197.html

>     perl-Module-Build

 "required to build perl-Error"
http://cygwin.com/ml/cygwin-apps/2007-12/msg00097.html

> Again, I stand by my point of not turning CPAN modules into
> Cygwin packages unless it is necessary.

  Agree with your basic point, but maybe somebody's got a plan that we don't
know about?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Jerry D. Hedden]

> >     perl-Error
>
>   "Required by git".
> http://cygwin.com/ml/cygwin-apps/2007-12/msg00094.html

This needs to be updated in git's 'requires' section in setup.ini.

> >     perl-ExtUtils-Depends
> >     perl-ExtUtils-PkgConfig
>
>  "buildtime-only requirement for the Perl GNOME bindings"
> http://cygwin.com/ml/cygwin-apps/2006-02/msg00196.html
> http://cygwin.com/ml/cygwin-apps/2006-02/msg00197.html
>
> >     perl-Module-Build
>
>  "required to build perl-Error"
> http://cygwin.com/ml/cygwin-apps/2007-12/msg00097.html
>
> > Again, I stand by my point of not turning CPAN modules into
> > Cygwin packages unless it is necessary.
>
>   Agree with your basic point, but maybe somebody's got a plan that we don't
> know about?

That seems to be the case.  I stand corrected.

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Eric Blake]

Jerry D. Hedden <jdhedden <at> cpan.org> writes:

> 
> > >     perl-Error
> >
> >   "Required by git".
> > http://cygwin.com/ml/cygwin-apps/2007-12/msg00094.html
> 
> This needs to be updated in git's 'requires' section in setup.ini.

It already has been.  It's just that the mirrors haven't caught up yet.

-- 
Eric Blake
volunteer cygwin git/perl-Error maintainer



--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Norton Allen]

Brian Mathis wrote:
> Because when you package something using a distro's packaging system,
> you can start to have other programs that depend on it install them
> automatically using the package system.  Also, installing from CPAN,
> while very easy to do, does not keep track or even know about a
> distro's package management system.  So if you wanted to remove it
> later, it is not easy to do, and you could easily run into problems
> where you have installed one version from CPAN, then another package
> requires that module, but because you installed via CPAN it doesn't
> know that, and will then install an older version, overwriting your
> CPAN-installed version.
>   
Just two more cents: No one mentioned that CPAN is a source distribution
and cygwin is a binary distribution. For those modules that require
compilation, pre-packaging means the module can be easily installed on a
system that doesn't have a compiler installed.


--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Igor Peshansky]

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

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 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.

> 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...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Svend Sorensen]

On Dec 12, 2007 7:46 AM, Igor Peshansky wrote:
> BTW, this problem must have been encountered (and, hopefully, solved) by
> other distros.  How does the Debian git package handle this?

Debian packages many CPAN modules. (My Etch system shows 1106
lib*-perl packages available.)

The Debian git package depends on liberror-perl.

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Archie Warnock]

Igor Peshansky wrote:
> 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...

I don't know how they solve dependencies, or if it has anything to do with
dependencies, but I can tell you that Fedora Core 8 (and earlier versions) have
a _lot_ of CPAN modules packaged as RPMs.

I, too, prefer to get my modules directly from CPAN but I do run into occasional
compilation problems from time to time.  At those times, it's really handy to
have the packages available.  But, as already mentioned, those should be fixes
that are passed upstream to the CPAN module owner/maintainer anyway.

-- 
Archie

-- Archie Warnock                       Internet: warnock@awcubed.com
-- A/WWW Enterprises                    http://www.awcubed.com
--       As a matter of fact, I _do_ speak for my employer.

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Brian Mathis]

On Dec 12, 2007 11:43 AM, Archie Warnock <warnock@awcubed.com> wrote:
> Igor Peshansky wrote:
> > 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...
>
> I don't know how they solve dependencies, or if it has anything to do with
> dependencies, but I can tell you that Fedora Core 8 (and earlier versions) have
> a _lot_ of CPAN modules packaged as RPMs.
>
> I, too, prefer to get my modules directly from CPAN but I do run into occasional
> compilation problems from time to time.  At those times, it's really handy to
> have the packages available.  But, as already mentioned, those should be fixes
> that are passed upstream to the CPAN module owner/maintainer anyway.
>
> --
> Archie
>

Fedora (and the other distros) do this because they understand that
for a really good working distro, you need to have everything on the
system managed by the system's package manager.  It doesn't really
matter that installing from CPAN is easy, because it always screws up
the dependencies on the system.

The same goes for compiling other packages from tar.gz files and
installing them without first rolling an rpm (for example).  Yes,
compiling is not hard, and it might make one feel that they are a more
empowered or advanced Admin, but it cannot be said emphatically enough
that compiling things from .tar.gz files should be the absolute last
resort way to get some software onto a system.

CPAN is sort of a gray area because it's another package manager in
and of itself, and perl modules mostly are not "compiled", but it
creates the same problems.

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Robert Pendell]

Brian Mathis wrote:
> On Dec 12, 2007 11:43 AM, Archie Warnock <warnock@awcubed.com> wrote:
>> Igor Peshansky wrote:
>>> 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...
>> I don't know how they solve dependencies, or if it has anything to do with
>> dependencies, but I can tell you that Fedora Core 8 (and earlier versions) have
>> a _lot_ of CPAN modules packaged as RPMs.
>>
>> I, too, prefer to get my modules directly from CPAN but I do run into occasional
>> compilation problems from time to time.  At those times, it's really handy to
>> have the packages available.  But, as already mentioned, those should be fixes
>> that are passed upstream to the CPAN module owner/maintainer anyway.
>>
>> --
>> Archie
>>
> 
> Fedora (and the other distros) do this because they understand that
> for a really good working distro, you need to have everything on the
> system managed by the system's package manager.  It doesn't really
> matter that installing from CPAN is easy, because it always screws up
> the dependencies on the system.
> 
> The same goes for compiling other packages from tar.gz files and
> installing them without first rolling an rpm (for example).  Yes,
> compiling is not hard, and it might make one feel that they are a more
> empowered or advanced Admin, but it cannot be said emphatically enough
> that compiling things from .tar.gz files should be the absolute last
> resort way to get some software onto a system.
> 
> CPAN is sort of a gray area because it's another package manager in
> and of itself, and perl modules mostly are not "compiled", but it
> creates the same problems.
> 
One thing I will add is the admin of the NetBSD system that I login to 
will not install anything unless it is in a package form.  So if someone 
requests a perl module then it has to be readily available as a package.


--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Reini Urban]

2007/12/12, Igor Peshansky <pechtcha@cs.nyu.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/

Re: Stop turning CPAN modules into Cygwin packages

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Reini Urban on 12/12/2007 6:32 PM:
> 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.

Yes - cygport automatically puts perl modules into vendor_perl.

> 
>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.

At which point I would retire perl-Module-Build as obsolete.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYI3X84KuGfSFAYARAsq2AJ9utMj4A4AEV6Iadg8BpSLuSeOsewCeOsHh
J6H/wqM5BRyOKHB42BvZNEg=
=Wbv4
-----END PGP SIGNATURE-----

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Igor Peshansky wrote:
> FWIW, some of these modules might be worth packaging as part of the Cygwin
> Perl package (in vendor_perl), rather than as separate packages.

Actually, I wish that we would NOT be doing this.  Separate modules
should be packaged separately, because otherwise, as we have it now:

1) updating a module requires repackaging (and redownloading, and
reinstalling...) the entire perl;

2) alternatively, the modules just get neglected and go stale;

3) some modules have binary dependencies which the perl core does not
have, e.g. XML-LibXML.

IMO these should all be broken out.  (Hint: as Eric just discovered,
packaging perl modules is *really* easy with cygport.  But then again,
I'm biased.)


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYKE3piWmPGlmQSMRCGqeAKCptGBM4umH2lKU7Rr+a/lwwgmjNgCg+Bzq
mDaZcZPr4QrW1AdmfrdJR+w=
=AokL
-----END PGP SIGNATURE-----

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Reini Urban]

2007/12/12, Yaakov (Cygwin Ports) <yselkowitz@users.sourceforge.net>:
> Igor Peshansky wrote:
> > FWIW, some of these modules might be worth packaging as part of the Cygwin
> > Perl package (in vendor_perl), rather than as separate packages.
>
> Actually, I wish that we would NOT be doing this.  Separate modules
> should be packaged separately, because otherwise, as we have it now:
>
> 1) updating a module requires repackaging (and redownloading, and
> reinstalling...) the entire perl;
>
> 2) alternatively, the modules just get neglected and go stale;
>
> 3) some modules have binary dependencies which the perl core does not
> have, e.g. XML-LibXML.
>
> IMO these should all be broken out.  (Hint: as Eric just discovered,
> packaging perl modules is *really* easy with cygport.  But then again,
> I'm biased.)

And I have to add that packaging perl is really hard, because I haven't got yet
the chroot trick to work when packaging it.
Modules hardcode absolute paths and install into hardcoded places, so it had
has to be done into the live tree and picking up the mass of new files
installed
there is a mess - done with a timestamp.

So changes are not making it fast enough into the big perl, unlike with
smaller perl-* 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/

Re: Stop turning CPAN modules into Cygwin packages

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Reini Urban wrote:
> And I have to add that packaging perl is really hard, because I haven't got yet
> the chroot trick to work when packaging it.
> Modules hardcode absolute paths and install into hardcoded places, so it had
> has to be done into the live tree and picking up the mass of new files
> installed
> there is a mess - done with a timestamp.

Did you look at how Gentoo deals with this:

http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/perl/perl-5.8.8-r4.ebuild

And in particular this patch:

http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/perl/files/perl-5.8.7-MakeMaker-RUNPATH.patch


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYibPpiWmPGlmQSMRCDsGAJ46aLiI44Wy123kIIPrUK6pNwewSACfW3NK
xfSJrDVL6xMF+G1f38yk/zQ=
=V8Dk
-----END PGP SIGNATURE-----

--
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/

Re: Stop turning CPAN modules into Cygwin packages

[Reini Urban]

Yaakov (Cygwin Ports) schrieb:
> Reini Urban wrote:
>> And I have to add that packaging perl is really hard, because I haven't got yet
>> the chroot trick to work when packaging it.
>> Modules hardcode absolute paths and install into hardcoded places, so it had
>> has to be done into the live tree and picking up the mass of new files
>> installed
>> there is a mess - done with a timestamp.
> 
> Did you look at how Gentoo deals with this:
> 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/perl/perl-5.8.8-r4.ebuild
> 
> And in particular this patch:
> 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/perl/files/perl-5.8.7-MakeMaker-RUNPATH.patch

Yes, and I don't like it. It really should be done by chroot or some 
postinstall fixup, so that the runtime loadpath is not compromised.
I also don't like what other distros have in their runtime loadpath.
Maybe they don't care so much about useless stat's in non-existing dirs, 
because stat is so much faster on their OS.

But now that 5.10 is officially out I'm trying it again over the weekend.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.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/