Re: ports and PBIs

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