This is the mail archive of the cygwin-apps 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: 64-bit: Missing perl modules


On 2014-04-08 15:52, Reini Urban wrote:
On Tue, Apr 8, 2014 at 1:01 PM, Achim Gratz wrote:
Reini Urban writes:
Nope.

Care to explain?

Already did. It's vastly easier to keep perl_vendor than to split it up.
For all parties.

Obviously, it's not, because perl_vendor hasn't been updated for almost two years. That is evidence enough to me that having to rebuild perl core and dozens of extra modules just to update or add a single CPAN module isn't feasible.

You can do individual perlrebase or wait for the full autorebase for
every XS installation.

Or do an ephemeral rebase that is taking the rebase map of the rest of
the system correctly into account.

Only if you register each and every user module with the system.
But we don't want that.

Yes, we do want to have packages for all Perl modules required by other packages. Telling users "oh, if you want to make this Cygwin package work, go install the modules from CPAN" is not a viable solution.

I know that you want to cygport every single perl module, but this is a very
extreme position.

No, it's not. We're not talking about all of CPAN here, just those modules which are needed by other packages; even with the typical recursiveness of CPAN dependencies, it's not all that many packages.

With the combined perl_vendor I'll do it as part of the build step and
the user only needs to wait for one rebase run.

You wouldn't need a special perlrebase for that, that's the whole point.

True. With proper EUMM and MB integration we would need no perlrebase.
But MB is a mess. And Module::Install even more. And I wonder what will
come up next. MB::Lite is already in the works just to bypass GNU make.

That's not what he meant. With _autorebase, there is no need for special rebasing of perl modules shipped in vendor_perl by the distro (or Ports), they will be rebased by setup during postinstall. As for those installed into site_perl, I think it would be an improvement to make rebaseall specifically look for those, knowing that they won't be registered otherwise. (Same could be said for Python's easy_install, Ruby's gem, R's CMD INSTALL, and PHP's pecl, except that not all of those have a site/vendor split.)

Sure, that's automatic of you care to package everything.
But updates come every week, not every two years.

In my case I have to package things anyway since I need to distribute
the to a bunch of machines that have no outward connection.  Besides the
need for an internal CPAN mirror, I'd generally not trust a random user
to run a CPAN update and make a judgment of whether or not everything
worked as expected.  Packaging some 300 Perl distributions really is
less work than any of the alternatives and keeping things up-to-date
isn't all that time-consuming so far.

+1

Fair enough. But then I would keep them uptodate with a simple cpan or
rsync, which is better than setup.exe.
No need to stop all services.
I maintain about 40 VM's this way, cross-version and platform.

cpan ensures proper testing and with CPAN::Reporter being integrated
the authors even get feedback.
strawberry perl does the same.

But that's not how Linux distributions manage Perl modules, and that's the issue here.


Yaakov


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