[116204] trunk/dports/net/libproxy/Portfile

[Clemens Lang]

On Tue, Jan 21, 2014 at 11:37:14AM -0800, David Evans wrote:
> The intent is to build using the perl5 that is installed or if not
> installed the default variant.  Isn't that reasonable? Why potentially
> install an additional perl version in addition to what is already
> installed if the port doesn't require it?

While that's reasonable your approach will not achieve this.

Consider the chance that libproxy is distributable. In that case, the
buildbot will install perl5 with its default variant, currently 5.16. It
will then build libproxy for perl 5.16. A user that might have a
different variant selected on the perl5 port will download the binary
archive for libproxy and still get libproxy build for perl 5.16.

If you want to implement this correctly you need to offer the variants
that perl5 offers, use the active_variants portgroup to ensure the
variants selected on libproxy and perl5 match, switch the default
variant on libproxy depending on the one used to install perl5 (if it is
installed) and set the default variant of libproxy to the same one as
perl5 (if perl5 isn't installed).
This approach will probably still not catch
  sudo port upgrade --enforce-variants perl5 -perl5.16 +perl5.18
which would break libproxy in this case.

Of course, this is just as complicated as offering a series of variants
that will depend on specific perl versions, so I don't see why anyone
would bother.

> If you go by your reasoning, port perl5 should never be used as a
> dependency, in which case, I'm not sure why it exists.

There might be cases where you just need *some* perl and don't care
which one it is, in which cases it should be safe to depend on perl5.
For all other cases you're correct, it's wrong to depend on perl5. IMO,
perl5 should be replaced with a perl_select port exactly for these
reasons.

> Should all ports that depend on perl5 be changed to depend on a
> specific versioned perl port (presumably the default perl version)
> although they would work just as well with another version? 

Maintainers (including me) often do that because it's a pain to support
all those perl versions.

-- 
Clemens Lang