Re: Stop turning CPAN modules into Cygwin packages
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/
Re: Stop turning CPAN modules into Cygwin packages
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
2007/12/12, Yaakov (Cygwin Ports) [EMAIL PROTECTED]: 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
-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/
Stop turning CPAN modules into Cygwin packages
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
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
On Dec 12, 2007 10:04 AM, Jerry D. Hedden [EMAIL PROTECTED] 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
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
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/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] 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
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
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
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: [EMAIL PROTECTED] -- A/WWW Enterpriseshttp://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
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
On Dec 12, 2007 11:43 AM, Archie Warnock [EMAIL PROTECTED] 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
Brian Mathis wrote: On Dec 12, 2007 11:43 AM, Archie Warnock [EMAIL PROTECTED] 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
2007/12/12, Igor Peshansky [EMAIL PROTECTED]: 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
-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 [EMAIL PROTECTED] -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
-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/
