Achim Gratz writes: > Marco Atzeri via Cygwin-apps writes: >> $ cygport GraphicsMagick.cygport list | grep perl5 >> /usr/lib/perl5/vendor_perl/5.32/x86_64-cygwin-threads/Graphics/Magick.pm >> /usr/lib/perl5/vendor_perl/5.32/x86_64-cygwin-threads/auto/Graphics/Magick/Magick.dll >> /usr/lib/perl5/vendor_perl/5.32/x86_64-cygwin-threads/auto/Graphics/Magick/autosplit.ix >> >> generic perl scripts should only pull "perl_base" > > For Base packages, yes. Otherwise it's a bit of a judgement call, but > I'd rather tie a package to the Perl version it was tested with (you can > always change the hint file later if you know it really doesn't need to > be repackaged after an update). You can't generally know in advance if > that works or not with a later Perl version, especially now that there > is talk about a version 7 that will most likely deprecate a number of > features and make others the default. Binary and feature compatibility > is only guaranteed within one major version.
In case it wasn't clear, the patched cygport only injects the dependency when a package touches one of the versioned perl directories, so the cases we've been discussing still need manual intervention. I think that's more in line with how Cygwin deals with that sort of thing; although in principle it could be changed to always inject a dependency and suppressing it based on either manual intervention or automatic determination (i.e. seeing that this is a Base package, in which case it should probably warn). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
