> While the environment variable PERL5LIB is added to the standard > include path, setting @INC in a BEGIN block replaces the standard > include path. So we could write a wrapper perl script that sets @INC > and then executes the real script. true - missed that, sorry. > I don't know how well written perl module Makefiles are, and how > accurate the dependency lists are, but I wouldn't put too much trust > in the dependencies listed in configure scripts of non-perl packages. > My experience is that they are often badly maintained and don't list > packages installed in default Linux distrubtions. So blindly copying > them over to the Makefile is not a policy I want to see documented in > the guide. Well, after some thinking - this is a good point. I'll maintain just a few non perl-packages and I am fighting with dependencies there as they are just not well tested in the configure script, true. The blind copy is not something that should be documented, however usually the prereq are quite accurate. Which leaves the point - testing as target or not? I would say yep, we should go for testing the perl modules so we should add the depends for it. As you are already working on something which brings us a Perl testing framework we should just wait for it until you have it ready for commit. Well, two hearts are inside me...one is fine with the solution above, the other one just says: go with the depends so that the tests of the modules succeed without skipping any test. I will continue my work on pkgsrc on the Perl modules and make sure that the tests are passed which is still a great effort left. Check out: http://www.netbsd.org/~rhaen/pkgsrc2cpan/ there is still a long way until this list contains just a few elements. Thanks for the discussion and your opinion about it. - Uli
Attachment:
pgpd_5zHeXrCU.pgp
Description: PGP signature