Re: DESTDIR vs `make install exec_prefix='

[Ralf Wildenhues]

Hi Harlan,

a post-scriptum to this:

* Harlan Stenn wrote on Sat, Apr 18, 2009 at 10:48:50PM CEST:
> Ralf wrote:
> > 
> >   ./configure --prefix=/usr/local
> >   make
> >   make install exec_prefix= DESTDIR=/tmp/dest
> > 
> > most likely copies executable files into the /tmp/dest directory, which
> > doesn't seem desirable either.  So, for both of these cases, Automake
> > 1.11 will not install executable files at all.

> Reading the doc pages for automake, it looks like automake should not
> install *anything* if either prefix or exec_prefix is the empty string,
> under any circumstances.

Well, of course my last message on this wasn't completely correct
either.  Sorry about that.

A better description is: for any installation directory variable, when
that variable is set to the empty string, then Automake 1.11 will not
install any files destined to that directory.

In what way is this different from previous?  Well, if you
  make install exec_prefix=

then bindir will will be `${exec_prefix}/bin', thus `/bin', thus
nonempty.  And the code currently only checks for nonemptiness of the
final variable, not intermediates.  So bindir will be populated unless
you also
  make install bindir=

This seems a bit awkward, but I can't see a way to easily distinguish it
from the case where the user typed
  make install bindir=/bin

and meant for files to be installed there.

> So if one was trying to effect some interesting local policy described
> above,
> 
>make install exec_prefix=/ DESTDIR=/tmp/dest
> 
> or
> 
>make install prefix=/ DESTDIR=/tmp/dest
> 
> would be the way to do that, right?

Sorry, I fail to parse this, but I guess it will do what you think it
does, namely install files in /tmp/dest/{bin,lib} etc.

Cheers,
Ralf

Re: DESTDIR vs `make install exec_prefix='

[Ralf Wildenhues]

* Jan Engelhardt wrote on Sat, Apr 18, 2009 at 11:49:13PM CEST:
> On Saturday 2009-04-18 22:45, John Calcote wrote:
> >
> >>No, I also thought of empty directories. Quote from above: "respective
> >>installation directory is empty.".

> >I'm sure he meant "...respective installation directory *variable* is
> >empty.". Doing anything based on whether the directory itself was empty is
> >meaningless,
> 
> Sure, but it was still a confusing read for too many parties ;-)

Sorry about that guys.  I meant the *variable*, but sure didn't write
that.

Cheers, and it is certainly reassuring to have people read closely!
Ralf

Re: DESTDIR vs `make install exec_prefix='

[Jan Engelhardt]

On Saturday 2009-04-18 22:45, John Calcote wrote:
>>>Oh, you mean if the value of the *variable* is empty (following the
>>>thread), not the directory itself.  D'oh, sorry, that should have been
>>>obvious to me from context.  Never mind.  :)
>
>
>>No, I also thought of empty directories. Quote from above: "respective
>>installation directory is empty.". But the puzzling thing was that
>>when using DESTDIR=$foo, $foo would normally be empty anyways
>>(in automated build systems like lbuild/koji/etc.)
>  
>
>I'm sure he meant "...respective installation directory *variable* is
>empty.". Doing anything based on whether the directory itself was empty is
>meaningless,

Sure, but it was still a confusing read for too many parties ;-)

Re: DESTDIR vs `make install exec_prefix='

[Harlan Stenn]

Ralf wrote:
> What I meant was this:
>   ./configure --prefix=/usr/local
>   make
>   make install exec_prefix=
> 
> with Automake 1.10.2, most likely ends up with an error at installation
> time, or with "install" overwriting files in the build tree or so.  And
> this:
> 
>   ./configure --prefix=/usr/local
>   make
>   make install exec_prefix= DESTDIR=/tmp/dest
> 
> most likely copies executable files into the /tmp/dest directory, which
> doesn't seem desirable either.  So, for both of these cases, Automake
> 1.11 will not install executable files at all.
> 
> This change in funtionality only affects cases where an installation
> directory has been set to the empty string.  It should not affect your
> use case for stow at all.
> 
> Hope that clears this up.

Reading the doc pages for automake, it looks like automake should not
install *anything* if either prefix or exec_prefix is the empty string,
under any circumstances.

So if one was trying to effect some interesting local policy described
above,

   make install exec_prefix=/ DESTDIR=/tmp/dest

or

   make install prefix=/ DESTDIR=/tmp/dest

would be the way to do that, right?

H

Re: DESTDIR vs `make install exec_prefix='

[John Calcote]

On 4/18/2009 2:32 PM, Jan Engelhardt wrote:

On Saturday 2009-04-18 22:06, Russ Allbery wrote:
   

Russ Allbery  writes:
 

Ralf Wildenhues  writes:
   

[1] I'm asking because Automake 1.11 will reliably not install files if
their respective installation directory is empty.  This is not yet
functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
consider $(DESTDIR) of course, only $(bindir) etc.
 

I must have misunderstood this, since it sounds like it would potentially
break any system where each binary package is installed into a separate
tree.  For example, stow packages are routinely installed with:

 ./configure --prefix=/usr/local
 make
 make install prefix=/usr/local/stow/package-version

DESTDIR cannot easily be used here because the stow layout should have
simple bin, etc, lib, etc. directories directly under that directory, not
with an extra /usr/local in the way.
   

Oh, you mean if the value of the *variable* is empty (following the
thread), not the directory itself.  D'oh, sorry, that should have been
obvious to me from context.  Never mind.  :)
 


No, I also thought of empty directories. Quote from above: "respective
installation directory is empty.". But the puzzling thing was that
when using DESTDIR=$foo, $foo would normally be empty anyways
(in automated build systems like lbuild/koji/etc.)
   
I'm sure he meant "...respective installation directory *variable* is 
empty.". Doing anything based on whether the directory itself was empty 
is meaningless, because the maintainer may have chosen to use the pkglib 
directory, for example, in which case, it will almost always be empty 
before you install - even to standard places - unless you're overwriting 
a previous installation, that is.


John

Re: DESTDIR vs `make install exec_prefix='

[Russ Allbery]

Harlan Stenn  writes:

> I know that GNU coding standards really want package developers to allow
> one to be able to override the prefix at "make install" time and "it
> should just work".  While I appreciate the goal and sentiment, sometimes
> that just isn't easy or feasible to do.

I disagree.  It's worked relatively well for years and with some caution
will continue to work fine for nearly all packages on modern OSes.  It
poses a few problems for libtool on particular architectures with weird
linking and shared library search issues, but those architectures are
becoming increasingly less common.

Thankfully, I just misunderstood the footnote entirely and nothing about
this change will affect that continued position.

-- 
Russ Allbery (r...@stanford.edu) 

Re: DESTDIR vs `make install exec_prefix='

[Jan Engelhardt]

On Saturday 2009-04-18 22:06, Russ Allbery wrote:
>Russ Allbery  writes:
>> Ralf Wildenhues  writes:
>
>>> [1] I'm asking because Automake 1.11 will reliably not install files if
>>> their respective installation directory is empty.  This is not yet
>>> functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
>>> consider $(DESTDIR) of course, only $(bindir) etc.
>>
>> I must have misunderstood this, since it sounds like it would potentially
>> break any system where each binary package is installed into a separate
>> tree.  For example, stow packages are routinely installed with:
>>
>> ./configure --prefix=/usr/local
>> make
>> make install prefix=/usr/local/stow/package-version
>>
>> DESTDIR cannot easily be used here because the stow layout should have
>> simple bin, etc, lib, etc. directories directly under that directory, not
>> with an extra /usr/local in the way.
>
>Oh, you mean if the value of the *variable* is empty (following the
>thread), not the directory itself.  D'oh, sorry, that should have been
>obvious to me from context.  Never mind.  :)

No, I also thought of empty directories. Quote from above: "respective
installation directory is empty.". But the puzzling thing was that
when using DESTDIR=$foo, $foo would normally be empty anyways
(in automated build systems like lbuild/koji/etc.)

Re: DESTDIR vs `make install exec_prefix='

[Harlan Stenn]

Russ wrote:
> Ralf Wildenhues  writes:
> > [1] I'm asking because Automake 1.11 will reliably not install files if
> > their respective installation directory is empty.  This is not yet
> > functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
> > consider $(DESTDIR) of course, only $(bindir) etc.
> 
> I must have misunderstood this, since it sounds like it would potentially
> break any system where each binary package is installed into a separate
> tree.  For example, stow packages are routinely installed with:
> 
> ./configure --prefix=/usr/local
> make
> make install prefix=/usr/local/stow/package-version
> 
> DESTDIR cannot easily be used here because the stow layout should have
> simple bin, etc, lib, etc. directories directly under that directory, not
> with an extra /usr/local in the way.

I know that GNU coding standards really want package developers to allow
one to be able to override the prefix at "make install" time and "it
should just work".  While I appreciate the goal and sentiment, sometimes
that just isn't easy or feasible to do.

When I build packages for the modules.sourceforge.net project (similar
to stow) I just make a point of running configure with the --prefix set
to the actual installation/execution path.

In this case I may use DESTDIR for one of two purposes:

- I want to install it "somewhere else" so I can tar up that subtree and
  unpack it later into the correct place
- I have to sneak the installation into a different place to install
  under a tree that accomodates am-utils and NFS-mounting the
  executables for a specific target architecture, and I keep all the
  "installed packages" for all the target architectures on a single
  partition.

For me this entire discussion smacks of some "fuzzy edges" between
mechanism (where to put things, and the spsecification of how the code
figure out where to look for things) and policy (where to put things,
and the specification of how the code figure out here to look for
things).

H

Re: DESTDIR vs `make install exec_prefix='

[Russ Allbery]

Russ Allbery  writes:
> Ralf Wildenhues  writes:

>> [1] I'm asking because Automake 1.11 will reliably not install files if
>> their respective installation directory is empty.  This is not yet
>> functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
>> consider $(DESTDIR) of course, only $(bindir) etc.
>
> I must have misunderstood this, since it sounds like it would potentially
> break any system where each binary package is installed into a separate
> tree.  For example, stow packages are routinely installed with:
>
> ./configure --prefix=/usr/local
> make
> make install prefix=/usr/local/stow/package-version
>
> DESTDIR cannot easily be used here because the stow layout should have
> simple bin, etc, lib, etc. directories directly under that directory, not
> with an extra /usr/local in the way.

Oh, you mean if the value of the *variable* is empty (following the
thread), not the directory itself.  D'oh, sorry, that should have been
obvious to me from context.  Never mind.  :)

-- 
Russ Allbery (r...@stanford.edu) 

Re: DESTDIR vs `make install exec_prefix='

[Ralf Wildenhues]

Hi Russ,

* Russ Allbery wrote on Sat, Apr 18, 2009 at 09:50:24PM CEST:
> Ralf Wildenhues  writes:
> 
> > [ dropping bug-coreutils ]
> 
> Dropping down to just the automake list.

Thanks.

> > [1] I'm asking because Automake 1.11 will reliably not install files if
> > their respective installation directory is empty.  This is not yet
> > functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
> > consider $(DESTDIR) of course, only $(bindir) etc.
> 
> I must have misunderstood this, since it sounds like it would potentially
> break any system where each binary package is installed into a separate
> tree.  For example, stow packages are routinely installed with:
> 
> ./configure --prefix=/usr/local
> make
> make install prefix=/usr/local/stow/package-version
> 
> DESTDIR cannot easily be used here because the stow layout should have
> simple bin, etc, lib, etc. directories directly under that directory, not
> with an extra /usr/local in the way.

I think you have misunderstood what I meant.  (I cannot tell you whether
you misunderstood Alfred, because I haven't understood him.)

What I meant was this:
  ./configure --prefix=/usr/local
  make
  make install exec_prefix=

with Automake 1.10.2, most likely ends up with an error at installation
time, or with "install" overwriting files in the build tree or so.  And
this:

  ./configure --prefix=/usr/local
  make
  make install exec_prefix= DESTDIR=/tmp/dest

most likely copies executable files into the /tmp/dest directory, which
doesn't seem desirable either.  So, for both of these cases, Automake
1.11 will not install executable files at all.

This change in funtionality only affects cases where an installation
directory has been set to the empty string.  It should not affect your
use case for stow at all.

Hope that clears this up.

Cheers,
Ralf

Re: DESTDIR vs `make install exec_prefix='

[Russ Allbery]

Ralf Wildenhues  writes:

> [ dropping bug-coreutils ]

Dropping down to just the automake list.

> [1] I'm asking because Automake 1.11 will reliably not install files if
> their respective installation directory is empty.  This is not yet
> functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
> consider $(DESTDIR) of course, only $(bindir) etc.

I must have misunderstood this, since it sounds like it would potentially
break any system where each binary package is installed into a separate
tree.  For example, stow packages are routinely installed with:

./configure --prefix=/usr/local
make
make install prefix=/usr/local/stow/package-version

DESTDIR cannot easily be used here because the stow layout should have
simple bin, etc, lib, etc. directories directly under that directory, not
with an extra /usr/local in the way.

-- 
Russ Allbery (r...@stanford.edu) 

DESTDIR vs `make install exec_prefix=' (was: Core-utils 7.2; building only 'su')

[Ralf Wildenhues]

[ dropping bug-coreutils ]

Hello Alfred,

* Alfred M. Szmidt wrote on Wed, Apr 15, 2009 at 07:17:42PM CEST:
>> So for maximum portability you should support this in your
>> package, too.  BTW, why do you state that overriding just $prefix
>> would be "almost always wrong"?
> 
>In the w32 arena, overriding $prefix at `make install' time is
>unilaterally *correct*.  Why can your staging area not mirror the
>structure of the eventual installation, with all alternative paths
>specified relative to $prefix, (as enshrined in GCS defaults)?  Do
>it sensibly, and you shouldn't need the DESTDIR kludge, so...
> 
> Using prefix is the real cludge, it has nothing to do with mirroring
> the staging area.

No, it's not, and the GNU Coding Standards contradict you on this point,
too.

> Consider `./configure --prefix=/shared
> --exec-prefix=' (yes, empty exec_prefix), if you now do `make install
> prefix=FOO', things will not install properly, this is exacly why we
> have DESTDIR.  Schemes like these are often used on systems that
> export their data using NFS.

Can you explain this in a bit more detail?  What do you expect to happen
in the case of an empty exec_prefix, with and without using DESTDIR?
That files to be installed below $exec_prefix are not installed at
all?[1]

As I see it, the only drawback for the user, when not using DESTDIR is
that you need to override all those installation directories at `make
install' time which were already overridden at configure time.  (The
drawback for the developer of the package and of autotools is that it
cannot be assumed any more that the installation directory is merely
prefixed with a staging path, rather than rewritten in a more general
way.)

Thanks,
Ralf

[1] I'm asking because Automake 1.11 will reliably not install files if
their respective installation directory is empty.  This is not yet
functional in Automake 1.10.2.  The test for emptiness in 1.11 will not
consider $(DESTDIR) of course, only $(bindir) etc.