Certain perl ports overlapping with perl-5.8.2 install

[parv]

in message <1075425257.93790.21.camel at gorf.lovett.com>,
wrote Ade Lovett thusly...
>
> With my dinkering around with perl5.8.2, I've run into something of a
> problem.
> 
> A number of ports, so far I have found:
> 
>       converters/p5-MIME-Base64
>       devel/p5-Storable
...
> are also part of the lang/perl5.8 port.  Some of the ports are
> newer than those in perl5.8, others are the same, still others are
> older.
> 
> However, what this does mean, that the following sequence:
> 
>       cd ${PORTSDIR}/lang/perl5.8; make install
>       cd ${PORTSDIR}/{one-of-the-ports-above}; make install deinstall
> 
> will end up removing parts of lang/perl5.8 port, resulting in much
> hilarity.

Did that actually happen?  Would not the port install otherwise
duplicate files in /usr/local/lib/perl5/site_perl/<version> instead
of /usr2/local/lib/perl5/<version>?

Nonetheless, it is indeed a problem expressed previously by some,
including myself.


> With our local ports tree, I've simply added code to these ports
> to tag them as BROKEN for appropriate PERL_VERSION value, and then
> start the slow slog through the rest of the ports/packages we
> build to adjust dependencies accordingly, when a port tries to
> bring in one of these "troublemakers" as a dependency.

What do you do after updating the ports tree?  Or rather a better
question would be do you use cvs, instead of cvsup, to update the
tree?


> This is a pretty disgusting hack, so I'm soliciting comments as to
> the right way to do this.

On way in three easy steps...

  - Find all the ports that would have been already installed as part
    of an installed perl port.

  - Based on the result, decide if there is pressing need to really,
    really install the port.

  - If a port explicitly requires a newer/older version of already
    installed module, then the port being installed should install the
    dependency, and be sure to actually use the quasi-duplicate
    dependency port/module.


Perl version checking needs to be independent from FreeBSD version.
Lack of that is the reason and need for ugly symlinks from
/usr/local/bin to /usr/bin (in FreeBSD 4.x).

Checking for Perl version should be done via variables already set
(say in /etc/make.conf or or via other appropriate means) to save a
few seconds; lacking that, invoke perl(1).

I do not see any way to identify, or get the list of, the installed
modules other than from perl(1) itself.  Suggestions?

Well, that's all i have on my mind so far...


  - Parv

--