Pavel Roskin <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> DESTDIR is completely unusable for this situation because DESTDIR
>> requires a complete replication of your final file system structure
>> under the DESTDIR root, which isn't how this normally works.  DESTDIR
>> is more intended for doing things like installing packages into a
>> separate file system that will eventually be mounted as /.

> I think you are wrong here. DESTDIR is often used in RedHat scripts, and
> I see no reason why it shouldn't work with AFS. Any real example will be
> appreciated.

Sure.  I want to install autoconf.  autoconf should look for all of its
private files in /usr/pubsw/lib/autoconf.  autoconf will be located in
/usr/pubsw/bin/autoconf.  In order for that to happen, autoconf has to
*install* into /afs/.ir/pubsw/Development/autoconf-2.13/share/{bin,lib}.
Those paths should not be hard-coded anywhere, because we may decide to
reorganize our package structure and autoconf may move into Config or
Programming or some other such section.  Instead, the /usr/pubsw paths
should be hard-coded, since they'll always be correct.

DESTDIR is unusable for this purpose, because DESTDIR would attempt to
install into /afs/.ir/pubsw/Development/autoconf-2.13/usr/pubsw/bin.
That's wrong.  That's not the structure of our package volumes.  And
there's no way of telling DESTDIR to do the right thing without changing
where autoconf expects itself to be after it's installed.

We could change the internal structure of all of our package volumes for
hundreds of software packages just to make DESTDIR happy, or we could just
set prefix at make install time which works right now and does what we
want.

-- 
Russ Allbery ([EMAIL PROTECTED])             <http://www.eyrie.org/~eagle/>

Reply via email to