Port dependencies on p5-Test-*

[Anton Berezin]

On Tue, Feb 26, 2008 at 03:15:59PM +0100, Dag-Erling Smrgrav wrote:
> Anton Berezin <tobez at tobez.org> writes:
> > Having discussed this at a whiteboard with lth@ (ah, the advantages of
> > face-to-face communication!), we came up with the following idea for
> > bsd.perl.mk's implementation.
> >
> > PERL_DEPENDS.  This will be the one which will be used most of the time,
> > since (p5-Test-* ports notwithstanding) it is actually difficult to come up
> > with cases when we want BUILD_DEPENDS without accompanying RUN_DEPENDS.
> 
> Mostly correct.  Imagine the situtation if MakeMaker wasn't in core; now
> imagine a Perl package that depends on something other than MakeMaker to
> generate the Makefile.
> 
> > PERL_DEPENDS=	\
> > 	p5-CGI.pm>3:www/p5-CGI.pm \
> > 	devel/p5-Time-HiRes>=1.86 \
> > 	textproc/p5-Regexp-Common
> 
> This is exactly what I was thinking of, which clearly shows that it
> *was* obvious :)
> 
> > The second one, which will be good for the vast majority of cases, looses
> > the package name, which is derived from the port name (by the way, the
> > p5-CGI.pm case can also be written like this;  we cannot, from the top of our
> > collective head, come up with a p5 port for which the package name base
> > differs from the port directory name).
> 
> I can: p5-libwww installs several Perl modules, none if which is called
> libwww.

This is a bad example because the dichotomy in question is not between
modules and ports, but between ports and packages.

> > Additionally, bsd.perl.mk maintains a little database for dual-life modules,
> > recording which version is present in which core.
> 
> Why?  If perl isn't installed, build that first.
> If perl is installed, use 'perl -M$MODULE -e "1;"' to check whether the
> module exists, or if a certain version is required, 'perl -e "use $MODULE
> $VERSION;"'

I think it is a bad idea, because

 - you need the "build that first" part (currently we create the complete
   list of direct dependencies before actually building anything; too many
   things to change with regard to our current procedure if we get rid of
   this constraint);

 - we introduce modules into the equation when before we had only ports and
   packages to worry about;

 - "use $MODULE" might have unanticipated side effects since a bunch of
   preamble code is executed [this is not a security risk as such (a
   malicious port can do worse things already), but as a general principle I
   don't like that];

 - it can take quite a bit of time to load if the module has lots of
   dependencies.

> > What do people think of this?  If we see positive reaction, we'll just
> > temporarily switch from coding in Perl to coding in make.  :-)
> 
> I'm perfectly willing to implement this myself, if you're allergic to
> make - or we can do it together at the Oslo QA Hackathon :)

Nono, I actually like make, in a perverse sort of way.  But the hackathon
would be a good place and time to do it.

Cheers,
\Anton.
-- 
We're going for 'working' here. 'clean' is for people with skills...
-- Flemming Jacobsen