From owner-freebsd-perl@FreeBSD.ORG Tue Feb 26 14:42:04 2008 Return-Path: Delivered-To: perl@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 857E21065675; Tue, 26 Feb 2008 14:42:04 +0000 (UTC) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [194.255.56.42]) by mx1.freebsd.org (Postfix) with ESMTP id 157A413C4D3; Tue, 26 Feb 2008 14:42:04 +0000 (UTC) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 5FA356D412; Tue, 26 Feb 2008 15:42:03 +0100 (CET) Date: Tue, 26 Feb 2008 15:42:03 +0100 From: Anton Berezin To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20080226144203.GC30778@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , ports@freebsd.org, perl@freebsd.org, Yen-Ming Lee , lth@freebsd.org References: <86zltpzrxt.fsf@ds4.des.no> <759236930802242324o614598d1i1a8ca3cc8c12478c@mail.gmail.com> <86prulibf4.fsf@ds4.des.no> <759236930802250245j646f5be5k8382bedbfb2a7c1e@mail.gmail.com> <868x19i6ky.fsf@ds4.des.no> <759236930802251702h694c4f5bn2c7c87c7c47c7cc@mail.gmail.com> <20080226122512.GA30778@heechee.tobez.org> <86ve4bsx8l.fsf@ds4.des.no> <20080226140456.GB30778@heechee.tobez.org> <867igrst0g.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867igrst0g.fsf@ds4.des.no> X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ports@freebsd.org, perl@freebsd.org, lth@freebsd.org, Yen-Ming Lee Subject: Re: Port dependencies on p5-Test-* X-BeenThere: freebsd-perl@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: maintainer of a number of perl-related ports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 14:42:04 -0000 On Tue, Feb 26, 2008 at 03:15:59PM +0100, Dag-Erling Smrgrav wrote: > Anton Berezin 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