From owner-freebsd-ports@FreeBSD.ORG Sat Sep 17 08:09:41 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0493B1065672 for ; Sat, 17 Sep 2011 08:09:41 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 953078FC24 for ; Sat, 17 Sep 2011 08:09:40 +0000 (UTC) Received: by wwe3 with SMTP id 3so5636568wwe.31 for ; Sat, 17 Sep 2011 01:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=ys5B0Tm+Kn8TG64yug6tZUMh7mlP4dcrbxsaxpeGHuk=; b=lIo5xeCLpl8qKRu9bKNcMLjkz5E10TfUBT43supcicdZQpkftShBMGF6JAA9o+z6tM hxRU+TJS8NM3E8Bhuc8RVqtXACOClvu8WlBnK4bpJC1hUSU/uyJydshwhsinW5s8C1qa NXzSuXpiI5G82oBqULsFSVoYcsF4EXq8MctHU= MIME-Version: 1.0 Received: by 10.227.176.200 with SMTP id bf8mr336376wbb.77.1316246978744; Sat, 17 Sep 2011 01:09:38 -0700 (PDT) Received: by 10.180.100.1 with HTTP; Sat, 17 Sep 2011 01:09:38 -0700 (PDT) Date: Sat, 17 Sep 2011 04:09:38 -0400 Message-ID: From: "b. f." To: Lawrence Stewart , freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Detecting dependencies X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 08:09:41 -0000 > On 09/15/11 07:06, chukharev at mail.ru wrote: > > Hi, > > > > There have been a discussion about finding interdependencies of ports. > > I have a relatively simple Python script for that. There is a pr > > ports/160007 > > to add its early version. Unfortunately, I missed a reply to it, so > > there is > > an issue which I have not yet addressed... > > > > Since that time, I added reverse dependencies with full ports tree scanning > > (1 h on my 2.5GHz notebook) and saving the tree (directed graph, actually) > > to a file, so that rescanning all ports tree is not needed. > > > > See http://code.google.com/p/porttree/ > > > > If there will be interest, scanning packages interdependencies could > > also be added. > > > > On a related subtopic, we also need a tool that identifies implicit > dependencies not captured in the ports Makefiles. I hacked the following > together earlier this year to smooth over the updating process when key > libraries get bumped (e.g. the gettext update at the time I wrote the > script was a nightmare). There were a tonne of ports which needed to be > updated even though they didn't explicitly record a dependency on gettext. > > https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh > > It's still quite rough and manually driven and is tied to portmaster at > the moment, but I use it routinely after a "portmaster -ad" to check > that no libs are missing dependencies. It works pretty well most of the > time, but definitely needs more finessing. I share it mostly to prove > the feasibility of the approach and in case anyone is curious. What, no check to see if the libraries listed in the DT_NEEDED tags are actually needed? And no kitchen sink? ;) There are scripts in ports/Tools/scripts that were intended to perform similar tasks, although they may be rougher than your script. > > I haven't thought the following ideas through a great deal and welcome > feedback, but I think the basic functionality/premise of this script > could be integrated into the ports framework so that at package > registration time, implicit deps are identified and marked in the > package database. A warning could also be generated that the port is > using deps not identified in the Makefile, and perhaps trigger a send-pr > to the port maintainer to let them know. ... > A script like this could also be integrated/called somehow from a tool > like portmaster during an update to ensure ports with implicit > dependencies on another port which has been updated are identified and > recompiled too so that we avoid the nasty problems that crop up with > missing library dependencies. Just as in the other *_DEPENDS lists, it was a conscious policy decision, for the sake of brevity and efficiency, that if port B requires port C, and port A requires port B, then libraries from port C will not be listed in the LIB_DEPENDS of port A, even if port A links directly to those libraries. But because of recurring problems with partial port updates, this policy has been criticized. I think that the last time the matter was raised, the consensus seemed to lean toward listing all needed libraries, but the amount of work involved in, and the likely disruption arising from, refactoring all LIB_DEPENDS in the tree dissuaded anyone doing so. b.