ports and PBIs

[Kostik Belousov]

On Sat, Apr 10, 2010 at 03:45:20PM -0700, Tim Kientzle wrote:
> Julian Elischer wrote:
> >On 4/10/10 12:07 PM, Tim Kientzle wrote:
> >>[1] Actually, PBI might work just fine even for
> >>embedded if we address the disk bloat issue. One
> >>approach would be to make
> >>/Package/Bar/libfoo-2.8.7.so
> >>a symlink or hardlink to
> >>/Package/Shared/libfoo-2.8.7.so-<MD5-hash>
> >>This gives easy sharing of identical files.
> >
> >yeah that's more or less what we were thinking..
> >hardlinks allow you to garbage collect when the last pbi that needs 
> >something is replaced/removed.
> 
> The point of /Package/Shared in this design is
> basically that it provides a list of all of
> the files that can be shared, so you
> avoid doing a full disk search to identify other
> places that might have this file.  You could
> accomplish the same goal by building and
> storing a database of sharable files somewhere,
> of course.
> 
> (Curiously, no one has mentioned filesystem-level
> deduping yet as the "big hammer" solution...  ;-)
> 
> The LD_LIBRARY_PATH issue is the most interesting
> problem here.  I don't immediately see a solution that
> doesn't include teaching ld-elf.so.1 about some form
> of per-application library path.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20100411/6b0f3d26/attachment.pgp