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
