All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] [RFC][PATCH] proper DESTDIR handling for device-mapper and LVM2
Date: Fri Mar 12 10:25:00 2004	[thread overview]
Message-ID: <4051D6EF.9070507@backtobasicsmgmt.com> (raw)
In-Reply-To: <20040312013822.C4622@homer.msp.redhat.com>

Alasdair G Kergon wrote:

> Thanks for the tidying: I'll work through this properly late next week.  
> (Office moves today.)  Quick comments: I'd prefer not to see DESTDIR in 
> Makefiles though: only in the template, and some (I thought most?) people 
> *do* want to pick up some include files etc. from their DESTDIR (they're not
> installed on their main system, or the ones on their system are different
> versions from the ones in DESTDIR which has the correct environment the
> software uses when it runs): perhaps that should be split into a separate
> configuration option (enabled by default)?

To keep DESTDIR only in the template, you'll have to replace the

bindir = @bindir@

lines (and similar) in make.tmpl with

bindir = $(DESTDIR)@bindir@

to avoid the problem of @bindir@ not including ${prefix}. Just don't 
bother putting $(DESTDIR) into prefix/exec_prefix at all, IMHO.

I can't speak to what everyone else does with DESTDIR, but most 
packaging systems point DESTDIR to an _empty_ subtree to do the install 
into, so they can package up all the resulting files. If someone wanted 
to build LVM2 on a system that had device-mapper _only_ installed into 
DESTDIR (i.e. /usr/lib did not contain libdevmapper.so, /usr/include did 
not contain libdevmapper.h, etc.) this would take a lot more work than 
what was already in the Makefiles, and even then it would tend to break 
because /usr/sbin/lvm would end up linked to

/foo/usr/lib/libdevmapper.so

instead of

/usr/lib/libdevmapper.so

and so /usr/sbin/lvm wouldn't run properly once the DESTDIR directory 
was used as a real environment.

So just to be completely redundant <G>, I'll reiterate the way I've 
always seen DESTDIR used: it's used _only_ at "make install" time to 
redirect the installation to a different path than the package was 
compiled to run from.

  reply	other threads:[~2004-03-12 15:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-11 23:10 [linux-lvm] [RFC][PATCH] proper DESTDIR handling for device-mapper and LVM2 Kevin P. Fleming
2004-03-12  2:36 ` Alasdair G Kergon
2004-03-12 10:25   ` Kevin P. Fleming [this message]
2004-03-16 21:27     ` Alasdair G Kergon
2004-03-16 21:38       ` Kevin P. Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4051D6EF.9070507@backtobasicsmgmt.com \
    --to=kpfleming@backtobasicsmgmt.com \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.