Date: Wed, 27 Feb 2008 11:40:57 +0100 From: Anton Berezin <tobez@tobez.org> To: Dag-Erling Smorgrav <des@des.no> Cc: ports@freebsd.org, perl@freebsd.org, lth@freebsd.org, Yen-Ming Lee <leeym@leeym.com> Subject: Re: Port dependencies on p5-Test-* Message-ID: <20080227104057.GA26979@heechee.tobez.org> In-Reply-To: <86ejayr969.fsf@ds4.des.no> References: <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> <20080226144203.GC30778@heechee.tobez.org> <86mypnrary.fsf@ds4.des.no> <20080226161635.GE30778@heechee.tobez.org> <86ejayr969.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 27, 2008 at 11:22:06AM +0100, Dag-Erling Smorgrav wrote: > Anton Berezin <tobez@tobez.org> writes: > > Dag-Erling Smorgrav <des@des.no> writes: > > > The rest of the ports tree checks every dependency right before building > > > it; I don't see why Perl ports should be any different. > > Er, I am not sure we understood each other here. What I was trying to say > > was this. Let's suppose we do not have perl installed. Let's suppose the > > user wants to build port A which depends on perl and on a module B which is > > both in perl's core and in a port B. Then the list of direct dependencies > > for port A will either include port B or not, depending on the version > > consideration. If we accomodate your suggestion, we cannot decide whether > > port B will be a dependency or not until we built and installed perl. I did > > not look in bsd.port.mk specifically to compose this mail, but my > > recollection is that it is not how this currently works. > > Every dependency is checked *right before it is built*. You stick it in > the list, but you have perl at the front of the list. It builds perl > first, then it gets to the module, checks 'perl -M$MODULE', finds out > that it's already there, and skips it. But then it needs to not record it as a dependency. Not just skip the build. > > Not really. What I don't like is that we still have to deal with ports (for > > building stuff) and packages (for recording dependencies), and dealing in > > addition to that with modules does not help us much with the first two. For > > example, when you do "perl -MX -e 'print $X::VERSION'", you get back a > > version which is OK. Now what? Now you *still* need to test whether p5-X > > is in fact installed, because if it is and you do not record it as a > > dependency you are in trouble, since the user can without any complaints > > pkg_delete p5-X and break your port. And if it is not installed then you > > are going to assume that it must be in the core perl since it is there, and > > you could be wrong on that, too (if the user just installed it from CPAN). > > But the ports system knows which package corresponds to which module, > since we put that in the dependency list: > > PERL_DEPENDS= Test::Unit:devel/p5-Test-Unit > > Or do you mean modules which are absorbed into core? Yes. For "normal" modules the existing package version check is perfectly adequate as it is, the suggested knobs simply serve as a syntax sugar (except PERL_TEST_DEPENDS, which is a bit more advanced). > Still a lot less work then building a bunch ports we don't need, which > is the current situation. We are arguing about a relatively minor thing here, namely about whether to keep the knowledge about dual-life modules in bsd.perl.mk or try to deduce it in runtime (and by proxy, whether to use the existing *package* version check or to do perl *module* version check), not about the usefulness of the suggested knobs, remember? \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080227104057.GA26979>