64-bit: Missing perl modules

[Yaakov (Cygwin/X)]

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