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

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

[Achim Gratz]

X-Git-Url: http://repo.or.cz/w/cygport/rpm-style.git/commitdiff_plain/f238f9c846690ba0d3ba259dee6c301f1ff98648

pkg_info.cygport: correct search order for Perl dependencies

* lib/pkg_info.cygpart: Correct search order for Perl dependencies and
  suppress auto-generation of Perl dependencies when NO_PERL_DEPS is
  defined.

Dependency generation for Perl at least is too simplistic and doesn't
take into account that some modules required or used might actually be
optional.  It tends to generate too long dependency lists that vary
with the Perl distributions already installed.

For starters, the search order should be the reverse of
@INC to skip dependencies that are built-in to perl already, but that
doesn't pick up those modules that are needed with a higher version
since only the presence of the module is detected.  Files in site_perl
shoud never be searched since these are local installs.  Files in
vendor_perl might be useful to check, however due to the version
problem it is better to inject the module dpenedencies from the
cygport file.  So skip those searches when NO_PERL_DEPS is defined,
which it will be for auto-generated cygport files for Perl
distributions (the information is pulled from CPAN/MetaCPAN).
---

diff --git a/lib/pkg_info.cygpart b/lib/pkg_info.cygpart
index 27b0696..a3d4d92 100644
--- a/lib/pkg_info.cygpart
+++ b/lib/pkg_info.cygpart
@@ -332,7 +332,12 @@ __list_deps() {
 
 	if check_prog perl
 	then
-		pldirs=($(perl -e 'print join(" ",@INC)'))
+		if defined NO_PERL_DEPS
+		then
+			pldirs=($(perl -e 'print join(" ",reverse grep !/(vendor|site)_perl/,@INC)'))
+		else
+			pldirs=($(perl -e 'print join(" ",reverse grep !/site_perl/,@INC)'))
+		fi
 		pldirs+=" ${DEPS_PATH//:/ }"
 		for pldep in $(find "${@//^_^/ }" -path 'usr/share/doc/*' -prune \
 				-o -path 'usr/share/help/*' -prune \


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

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

[Yaakov Selkowitz]

On Sun, 2015-02-22 at 23:08 +0100, Achim Gratz wrote:
> pkg_info.cygport: correct search order for Perl dependencies
> 
> * lib/pkg_info.cygpart: Correct search order for Perl dependencies and
>   suppress auto-generation of Perl dependencies when NO_PERL_DEPS is
>   defined.
> 
> Dependency generation for Perl at least is too simplistic and doesn't
> take into account that some modules required or used might actually be
> optional.  It tends to generate too long dependency lists that vary
> with the Perl distributions already installed.
> 
> For starters, the search order should be the reverse of
> @INC to skip dependencies that are built-in to perl already, but that
> doesn't pick up those modules that are needed with a higher version
> since only the presence of the module is detected.  Files in site_perl
> shoud never be searched since these are local installs.  Files in
> vendor_perl might be useful to check, however due to the version
> problem it is better to inject the module dpenedencies from the
> cygport file.  So skip those searches when NO_PERL_DEPS is defined,
> which it will be for auto-generated cygport files for Perl
> distributions (the information is pulled from CPAN/MetaCPAN).

Could you provide more detail here so I can better understand the
problems?  Do you have an example of the difference in dependencies with
your patch?  Don't we want to depend on newer versions in vendor_perl if
they are present?  And can I see your auto-generation script for CPAN
packages, is it a candidate to include in cygport itself?

--
Yaakov

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

[Achim Gratz]

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