Steven Hartland wrote:
Would fix this particular package but again: how many others
do this? Maybe this is something that BSDPAN could / should
override?
It might be possible, you should talk to the BSDPAN maintainer.
Kris
___
freebsd-ports@freebsd.
- Original Message -
From: "Kris Kennaway" <[EMAIL PROTECTED]>
I think something is not quite right in your analysis, because perl does
not depend on any external perl modules (it cannot, by definition).
I know what your saying there Kris, this shouldn't happen. So I've
spent some t
Kris Kennaway wrote:
I think something is not quite right in your analysis, because perl
does not depend on any external perl modules (it cannot, by definition).
I ran into something like this when I was switching from a threaded perl
to an unthreaded perl. It wasn't possible to just use a po
On Sat, 2008-03-01 at 14:53 +0100, Kris Kennaway wrote:
> Steven Hartland wrote:
> > Seems portupgrade can easily break the perl install.
> >
> > How? Well there are various modules which can be updated
> > but are also part of the base perl and are hence required.
> >
> > A good example of this
Steven Hartland wrote:
Seems portupgrade can easily break the perl install.
How? Well there are various modules which can be updated
but are also part of the base perl and are hence required.
A good example of this is ExtUtils::MakeMaker. If you
uninstall any version of this port your done for,
Seems portupgrade can easily break the perl install.
How? Well there are various modules which can be updated
but are also part of the base perl and are hence required.
A good example of this is ExtUtils::MakeMaker. If you
uninstall any version of this port your done for, as
trying to build it r
