From owner-freebsd-questions@FreeBSD.ORG Tue Oct 4 16:19:07 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F29F816A41F for ; Tue, 4 Oct 2005 16:19:06 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id A868143D45 for ; Tue, 4 Oct 2005 16:19:06 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from [208.206.151.59] (host59.gtisd.com[208.206.151.59]) by comcast.net (rwcrmhc11) with ESMTP id <2005100416190401300j16gle>; Tue, 4 Oct 2005 16:19:05 +0000 Message-ID: <4342AB77.90209@computer.org> Date: Tue, 04 Oct 2005 11:19:03 -0500 From: Eric Schuele User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Csaba Henk References: <43416280.80403@computer.org> <20051004115814.GA99762@beastie.creo.hu> In-Reply-To: <20051004115814.GA99762@beastie.creo.hu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Determining what a port will install... (more than pretty-print-*) [Soln] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2005 16:19:07 -0000 Csaba Henk wrote: > On Mon, Oct 03, 2005 at 11:55:28AM -0500, Eric Schuele wrote: > >>Hello, >> >>Some time back I posted a question regarding how to determine what >>ports/packages would need to be installed on my machine when I install a >>new (new to the local machine) port. >> >>For example, if I do not presently have openoffice installed... what >>will get installed when I 'make install clean' it? Note that I want the >>differences between what is needed to build/run the port and what is >>already present on the machine. >> >>At the time no one responded with a clear way to do this... so I finally >>had a few minutes to write a script to do it for me. I thought someone >>else might find it useful... So I'm posting it here for comments and >>thoughts (be gentle, I'm new to awk). > > > Here is an improved/spoiled (decide by yourself) version. Improved. > I aimed to > sport a more orthogonal design and avoid some gotchas I run into (see > comments in awk code). > > -------------------------------- > #! /bin/sh > > # Script to determine the differences between what is necessary for > # a port, and what is already present on the local machine. > > awkprgt='{ > count = 0 > pkgs = "" > for(i=5; i<=NF-2; i++) { > pkg = $i > > # the "if" is here to hack it around when you get: > # This port requires package(s) "" to build. I never ran into this case. > if (pkg != "\"\"") { > if (index(pkg, "\"") == 1) > {pkg = substr(pkg, 2, length(pkg)-1)} > if (index(pkg, "\"") > 1) > {pkg = substr(pkg, 1, length(pkg)-1)} > > if ( system("pkg_info -e " pkg) == 1) { > pkgs = pkgs " " pkg > count++ > } > } > } > > if ( count ) { > print "You need the following (%s) perequisites:" > print pkgs > } > else { > print "All (%s) prerequisites are present." > } > > } I did see this on a few ports... but decided to handle it in the same fashion as `make pretty-print*`, for better or worse. My initial response was to do as you did (and I believe that IS the right thing)... but I fell back to what the make target did. But I prefer your soln. > END { > # triggered, eg., by audio/artswrapper (on my box, at least) > if( ! FNR) { > print "Bogus (empty) %s dependency information" > } > } > ' > > awkit() { > # Resolve "%s"-s via sed is a blunt hack > # but good enough here and thus we don't have > # to care about the number of occurrences > awk "`echo "$awkprgt" | sed s/%s/$1/g`" > } > > > make pretty-print-build-depends-list | awkit build > > make pretty-print-run-depends-list | awkit run > -------------------------------- > > Alas... while I was making these changes, I succeeded to recall why I > abandoned my earlier attempt to put together a script which fulfils this > (highly desired) functionality. I highly desire this too... but my initial post (some months ago) received less attention than I expected. I find this functionality very useful, and was surprised solution didn't already exist. > > Because all such scripts are fundamentally broken. > > When make decides which ports to pull in, it doesn't only use the flat > data of build and run dependencies, but uses its full Turing complete > computing power. Eg., what happens when a port needs a postscript > interpreter? Then do the pretty-print(s) not provide the useful information they appear to? I mean, If the above were true then they would have no value... and should go away. Or do they provide true but incomplete information? > Should it use the AFPL or the GNU edition as a dependency? > Of course, doing a favor toward one of them (and taking away user's > choice) is unacceptable. So what happens is that make directly checks > whether the gs executable is present. > > See, for example, print/gv. Your script's output will include > ghostscript-gnu-7.07_13 both as a build and a run dependency. > Yet when I type make, my ghostscript-gnu-7.07_12 installation will > be happily utilized as the following output snippet shows: Is this not acceptable behavior since it is just a port revision? Shouldn't the revision be compatible in every way with the vendor's release? > > => Checksum OK for gv-3.6.1.tar.gz. > ===> Patching for gv-3.6.1 > ===> Applying FreeBSD patches for gv-3.6.1 > ===> gv-3.6.1 depends on executable: gmake - found > ===> gv-3.6.1 depends on executable: gs - found > ===> gv-3.6.1 depends on shared library: Xaw3d - found > ===> gv-3.6.1 depends on shared library: X11.6 - found > ===> Configuring for gv-3.6.1 > > The approach taken by FreeBSD's ports is to have more flexibility but > less predictability, and now we have to live with it. Maybe the Gentoo > guys are the ones who succeeded to find the proper balance between these > two quantities -- they made up a mini-markup-language for denoting > dependencies, which is clever enough to cover all cases but it's still > just an easy to parse flat data. > > One solution for FreeBSD could be digging deep into the make backend of > the ports framework and insert the necessary hooks everywhere to produce > a reliable dry-run. > > Or severely refactor the whole ports framework and switch to Gentoo style > dependency handling. This won't happen any soon IMHO as ports API > changes should be pushed through all ports... > > (OFF: to have a bit of bitter laugh, I think Gentoo's portage suffers > from a fundamental design flaw: they can't tune installation prefixes > (which would be necessary to make it an acceptable cross platform 3rd > party package manager, akin to pkgsrc, but it would have other uses, too). > This is again such a thing which can be changed only by rewriting all of > their e-builds.) > > Regards, > Csaba > Thanks for contributing to the script. -- Regards, Eric