From owner-freebsd-current@FreeBSD.ORG Sun Apr 11 19:13:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF3B106566B; Sun, 11 Apr 2010 19:13:13 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id D8EA38FC43; Sun, 11 Apr 2010 19:13:12 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1698760qwi.7 for ; Sun, 11 Apr 2010 12:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yAx/NwFGYiqLiuiNW4PpKtksMT51m28Pp1vlvTaPFKY=; b=uaAzjqI0g01OIzL8tvFl7a1e/p1ynl9xY3+llPch8LbGn1TfUgX4L7jH4GjhJVUYU1 /jTD5gLXwTrk4ZlAQ+Z+b7Sri5a+FOnK57M4QYEY3kJ/dv53oQ4LFOHOAixVS0SBy5Us FM/Tx4YgDoC/kFZBiAE26uXD4nN2XVk+ZB9Jk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HG1Mm1RmmKtWnEUqLAh3wNvvmK91Dg/d9RuZX5tUaId7Fyxqp6Tko2TzfS1QMmA+W/ l42DMSNS9UI2e4H+1Yn3N8XO61ImRN7CfJrNldpsaaHTbuRGq1JPWxZynMh0wzkMmq9F /CuO2ui+jLnzWXF2S/h8OTVLjCzEuZImB1OYs= Received: by 10.229.225.73 with SMTP id ir9mr4447036qcb.22.1271013191917; Sun, 11 Apr 2010 12:13:11 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id w30sm4919003qce.22.2010.04.11.12.13.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Apr 2010 12:13:11 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC21F48.8090407@elischer.org> Date: Sun, 11 Apr 2010 12:13:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kostik Belousov , ports@freebsd.org, FreeBSD Current References: <4BC03ABA.6090309@elischer.org> <4BC0CC6F.7010009@freebsd.org> <4BC0E9AE.1000904@elischer.org> <4BC0FF80.4000907@freebsd.org> <20100411102723.GT2415@deviant.kiev.zoral.com.ua> <4BC213A5.4020104@elischer.org> <20100411184406.GV2415@deviant.kiev.zoral.com.ua> In-Reply-To: <20100411184406.GV2415@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 19:13:13 -0000 On 4/11/10 11:44 AM, Kostik Belousov wrote: > On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote: >> On 4/11/10 3:27 AM, Kostik Belousov wrote: >> >>> I already pointed in the other reply in this thread, $ORIGIN dynamic >>> token should solve the issue. See >>> http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=en&a=view >> >> yes, teh question I have since I am not alinker expert is do we >> support it? the link you give is for Solaris I think.. > > It is in three for HEAD, RELENG_8 and RELENG_7. thank you. This will I think as you suggest, make a significant difference. the question I have is "is it re-evaluated for each library"? So, to recap: what we were thinking is something along the lines of the following: an example with 2 PBI apps created at the same time (part of the same set) application 1 --------> libraryA - - (originally) - - ->library B | / | |link / |link | /-----------(y)-------/ | v / v common area dd-mm-yy library A ------(x)------------>library B ^ ^ |link |link | | | | application 1 --------> libraryA - - (originally) - - - ->library B library A and B in app 2 are deleted the idea that all the PBIs developed as part of a release set (labeled as set dd-mm-yy in this example, would have identical libraries in them and would thus be candidates for "library consolidation". The question is and I guess it's not really that important, whether satisfaying a dependency in library A due to application 1 will use path (x) or path (y). certainly we would need to label the versions of the libraries in the common area with a hash or something, or maybe some other unique label. (port sequence number plus build args?) so that we don't use a copy of the library that is not really suitable for that app. A really top class effort would be ab;e to know hte set of build options on a library that would make the outcome "acceptable". but I doubt that we want to go that far. if a person takes PBIS from set "01-01-2011" hey will tend to find common libraries. butit for some reason they need to take something from set "01-01-2009" (i.e. an old PBI, for some compatibility reason) it is guaranteed to work, despite the fact that there may well be collisions between library versions, because it will not be linked with those in the common area that do not match and will instead be linked with its own copies. Julian