Re: [cygport] pkg_info.cygport: correct search order for Perl dependencies

[Achim Gratz <Stromeko at nexgo dot de>]

Yaakov Selkowitz writes:
> Could you provide more detail here so I can better understand the
> problems?

There are lots of Perl distributions that can optionally use some module
when available.  I often have those modules installed since I need them
for testing or something else entirely and then the corresponding
distribution will be picked up by cygport as a dependency.

> Do you have an example of the difference in dependencies with
> your patch?

Off-hand, I think cpanm is the most prominent example (or was, I haven't
checked lately).  It's supposed to work standalone (except for tar as an
external dependency).  If you happen to have some totally optional
modules installed, they become dependencies, which totally defeats the
purpose of cpanm.

> Don't we want to depend on newer versions in vendor_perl if
> they are present?

I'd say no.  It's not that there are no errors to be found in META files
(I correct those where I know about them), but if a distribution says it
doesn't care about the version of a module or the module version built
into Perl is sufficient, then I don't see why we should force
installation of a newer moduleâ Unless that fixes a bug, but again I can
patch that extra bit in and forget about it.

I suggest that a workable strategy for cygport to find the dependencies
might be this: look at the runtime dependencies from the META.yaml or
META.json file after compilation, map those module names to perl
distributions and use those (with a "perl-" prefix) as dependencies.
The important bit here is to check which of those are in Perl core and
drop them.  Again, you will occasionally want to modify that result, so
there should be ways to both add a dependency (already there) or drop
one.

> And can I see your auto-generation script for CPAN

Let me know which email address I should send it to.

> packages, is it a candidate to include in cygport itself?

At the moment I'd say no since it's historically grown (it started as a
way to deal with the concealed dependencies via perl_vendor).  I wanted
to clean it up for a while, for instance to use the new MetaCPAN::API
interface only (at the moment it's a wild mixture of CPAN and MetaCPAN)
and then pull out some parts that have to do with how I organize the
packaging locally into a support script.  But just the part described
above might be easier to get at and implement.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables