Re: deploying libraries and executables from a staging area

[Noel Yap]

On 9/21/06, Ralf Wildenhues <address@hidden> wrote:

</snip>

Thanks for the detailed definitions and notes.  They help a lot.


> Now, please answer the crucial missing questions:
> 1) Does the stuff (programs and libraries) you are building in your
> package depend upon installed libraries that are not yet at their
> ultimate position?

No.

> 2) Do any libraries that you depend upon have themselves dependencies
> that are not yet at their ultimate position?

No.

> 3) For any library in (1) and (2): are they libtool libraries?  If yes,
> please post the *.la file.  In any case (libtool libs or not), please
> post `objdump -p libfoo.so' for them.

n/a unless I misunderstood and you want the objdump -p of all
installed libraries.

> Now that you mentioned /some/read-only/dir and /some/read-write/dir, one
> more question:
> Can /some/read-write/dir be accessed in the form such as
>   /some/prefix/some/read-only/dir
>
> ?  If yes, let's define /DESTDIR/ as `/some/prefix' and hence speak only
> of DESTDIR from now on.

No.  I'll ask around to see if such a change to our filesystem can be
made, but if not, is there an alternative to DESTDIR?

> Just to give a couple more hints why the distinctions are important:
> imagine that at the time you build your code (and install it into a
> temporary, let's say DESTDIR, staging tree), there is both a set of
> good third-party libraries (ones you wish to link against) below
> $DESTDIR$prefix, and a set of bad third-party libraries below $prefix,
> then it is important that you link against the good ones.
>
> Later, at execution time, imagine that your programs and libraries, and
> the set of good third-party libraries have been moved to their ultimate
> position, imagine someone else builds a newer version of your package
> and installs it below $DESTDIR$prefix.  Your programs and libraries
> below $prefix should continue to work, however: they must not contain
> run paths pointing to below $DESTDIR.
>
> Since the respective old and new set of libraries may just be
> incompatible for some reason (a newer version; or think about cross-
> compiling for a different system), the path distinction is fundamentally
> important for these cases.

I'll have to mull this over to grok it completely, but I think I have
the gist of it.

Thanks,
Noel