Port dependencies on p5-Test-*

[Yen-Ming Lee]

2008/2/25, Dag-Erling Smørgrav <des at des.no>:
> "Yen-Ming Lee" <leeym at leeym.com> writes:
> > For Makefile.PL, all dependencies are listed in 'PREREQ_PM' so it's
>  > hard to tell which ones are really needed and which ones are needed
>  > only for tests.
>
> I assume that in the vast majority of packages that are not themselves
>  named p5-Test-*, none of the Test::* modules are required.
>
>  The sed script I posted may remove too much from Makefile.PL, and
>  Build.PL, but that doesn't actually matter as long as the port's
>  BUILD_DEPENDS and RUN_DEPENDS are correct; it only means that
>  Makefile.PL won't verify that they're there.  The ports tree's
>  dependency system guarantees that they are, and even if they aren't, the
>  build will fail.
>

Okay, I agree to remove these Test::* from RUN_DEPENDS since they
should be only used for tests, however I still want to keep them in
BUILD_DEPENDS so that it will be easier when developers want to 'make
test' (I know that we don't do it for p5-* perl, but I do).

So, there are two problems in the current perl ports, and either one
of them will generate the overkill dependencies:
1. depends on the modules which are in perl core list already
2. put the dependency-for-test-only (say Test::*) in RUN_DEPENDS

I wrote a script to catch both problems, and I'll update it daily here:
http://people.freebsd.org/~leeym/p5-lint.txt

To simplify the dependency tree for p5- ports, we should start with that list.

For case 1, someone prefers to use the latest version while someone
prefer to simply the dependency. I myself prefer the latter. I guess
it needs further discussion to make a consensus.

And, note for case 1: If some modules are needed for some features in
newer version, it should use versioned dependency instead and specify
the minimum version needed. My script will check with Module::CoreList
for that specific version.

For case 2, I guess the consensus is to keep RUN_DEPENDS as simple as
possible, right?

Regards,
-- 
Yen-Ming Lee <leeym at leeym.com>