Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Alfred M. Szmidt]

   [[[ To any NSA and FBI agents reading my email: please consider]]]
   [[[ whether defending the US Constitution against all enemies, ]]]
   [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

 > My first thought was that Autoconf is a relatively trivial attack vector 
 > since it is so complex and the syntax used for some parts (e.g. m4 and 
 > shell scripts) is so arcane.  In particular, it is common for Autotools 
 > stuff to be installed on a computer (e.g. by installing a package from 
 > an OS package manager) and then used while building.  For example, 
there 
 > are large collections of ".m4" files installed.  If one of the m4 files 
 > consumed has been modified, then the resulting configure script has been 
 > modified.

   Can anyone think of a feasible way to prevent this sort of attack?

One cannot prvent it, only make it a bit harder -- possibly with the
draw back of making it more harder to find such attacks in the future
but that is hypothetical.

   Someone suggested that configure should not use m4 files that are
   lying around, but rather should fetch them from standard release points,
   WDYT of that idea?

It would be trivial to modify things after it has been fetched, make
the release, and you're back at square one.  One would also need to
keep a list of which m4 files to fetch, people write them for their
packages as well.

Requiring network access to build, or develop a GNU package is also
just a non-starter ... and if it is not requried, well you can just
not use it and again back at square one.


The idea of signing Autoconf offical M4 files is problematic, why
would you trust such a signature?  The attack on xz was performed by
the maintainer, given any rouge maintainer you'r shit ouf of luck.

Re: automated release building service

[Alfred M. Szmidt]

   * Such an automated release building service is a piece of SaaSS.

CI is not SaaSS, how is it different?

 I can
 hardly imagine how we at GNU tell people "SaaSS is as bad as, or worse
 than, proprietary software" and at the same time advocate the use of
 such a service.

Unnecessary hyperbole and FUD, nobody is caliming anything of the
sort.

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Alfred M. Szmidt]

   Bluntly, I don't think it would help with security.  The attacker would
   just have to disable or adjust the distcheck target to seemingly pass.

Yeah, it should be noted that the way the backdoor got into the code
was by the _co-maintainer_ -- distcheck or not, would not have
mattered, automake or not, would not have mattered.  The individual
could have sneaked in code changes into the release tar-ball just as
well -- Github presented two sets of files one could download (direct
from git, and "release").

The deviousness of this backdoor should not be understated, it was a
long game of over two years in work and technological improvments will
simply not mitigate it.

   Relying on something in a code repository to tell whether the repository
   is secure is akin to tying a dog with sausage.

   For security proper, the verification code needs to be held elsewhere,
   not compromisable along with the thing it's supposed to verify.

   Analogously, you don't run a rootkit checker on the system that's
   potentially compromised, because the rootkit may hide itself; you boot
   off secure media and then use the tools in it to look for the rootkit in
   the potentially-compromised system, *without* handing control over to
   it.

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Alfred M. Szmidt]

   > It is not yet clear if the 
   > maintainer intentionally did this, or if the changes were introduced via 
   > a compromise of his computer.

   I think it is pretty clear by now. [1][2][3]

There is a bit more to it all than just this -- the maintainer wasn't
responsible (Lasse Collin), the co-maintainer -- JiaT75 (or what you
might call the person) was from the looks.

   [1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
   [2] https://news.ycombinator.com/item?id=39865810
   [3] https://www.youtube.com/watch?v=Kw8MCN5uJPg

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Alfred M. Szmidt]

 - Have them distributed (automake's default).  This means that
   they will be build in the srcdir, not in the builddir: of
   course, this only affects the maintainer, since for a user that
   builds the package from a tarball those files should *not* be
   rebuilt, hence there is no problem even if the user's srcdir is
   read-only.

This has always been the right way to do things.

 - Don't distribute the generated info files.  [...]  In this
   case, the user will have to to have the 'makeinfo' program
   available to build them.

Please don't do this, it causes all kinds of headaches, like the small
fact that makeinfo will now be required to bootstrap.

Re: default -g ??!?

[Alfred M. Szmidt]

The reason why users are helpless without debugging symbols is if a
program crashes, all they can look at are the machine registers at the
state of the crash.  This is completely useless for figuring out why
the program crashed, or getting help from another hacker to figure out
why it crashed.

Re: Automake and Texinfo: clean the info or pdf file

[Alfred M. Szmidt]

   >> � �If I call :
   >> � �$ make
   >> � �The .info file is built.
   >>
   >> � �If I call :
   >> � �$ make clean
   >> � �The .info file is not cleaned.
   >>
   >> � �It is the same thing for pdf, if I call :
   >> � �$ make pdf
   >> � �The .pdf file is built.
   >>
   >> � �If I call :
   >> � �$ make clean
   >> � �The .pdf file is not cleaned.
   >>
   >> � �Is there a rule which clean the .info or .pdf file?
   >>
   >> That is as intended, documentation is supposed to be distribtued with
   >> the tarball so that users do not need to install whatever tools are
   >> needed to generate it, hence why `make clean' does not remove them.
   >> If you wish to remove all generated files, you'll need to do `make
   >> distclean'.

   Not so strightforward.  'make distclean' should remove all generated
   files that don't included into distribution.  Therefore, .info should
   be left inplace, same as Makefile.in (both generated, but included
   into tarball), but Makefile (plain "final" one) should be removed
   because generarated and not included into tarball.

You are ofcourse completely correct, I was half a sleep when I wrote
the reply and was really refering to make maintainer-clean which does
remove it.  Thanks for the correction.

Re: Automake and Texinfo: clean the info or pdf file

[Alfred M. Szmidt]

   >If I call :
   >$ make
   >The .info file is built.
   > 
   >If I call :
   >$ make clean
   >The .info file is not cleaned.
   > 
   >It is the same thing for pdf, if I call :
   >$ make pdf
   >The .pdf file is built.
   > 
   >If I call :
   >$ make clean
   >The .pdf file is not cleaned.
   > 
   >Is there a rule which clean the .info or .pdf file?
   > 
   > That is as intended, documentation is supposed to be distribtued with
   > the tarball so that users do not need to install whatever tools are
   > needed to generate it, hence why `make clean' does not remove them.
   > If you wish to remove all generated files, you'll need to do `make
   > distclean'.

   Now, when I call :
   $ make clean
   the .pdf file is removed correctly :-)

   If I call :
   $ make distclean
   the .info file isn't removed but the .pdf file and the Makefile are removed.
   I am suprise to see my Makefile disappears and I must run the configure 
script in order to build it again.
   The only way I found to remove my .info file is to call the rm command 
manually.

Sorry, I was refering to maintainer-clean.  distclean is supposed to
make the source directory look as if it was just an extracted tarball,
and the info files are supposed to be distributed as part of the
distribution.

   What target can help me to remove the .info file built with the make command?
   Why the Makefile is removed when I call the distclean target?

maintainer-clean will remove it, but what are you trying to achive?
It is on purpose that the info files are distributed as part of the
source tree.

Re: Automake and Texinfo: clean the info or pdf file

[Alfred M. Szmidt]

   If I call :
   $ make
   The .info file is built.

   If I call :
   $ make clean
   The .info file is not cleaned.

   It is the same thing for pdf, if I call :
   $ make pdf
   The .pdf file is built.

   If I call :
   $ make clean
   The .pdf file is not cleaned.

   Is there a rule which clean the .info or .pdf file?

That is as intended, documentation is supposed to be distribtued with
the tarball so that users do not need to install whatever tools are
needed to generate it, hence why `make clean' does not remove them.
If you wish to remove all generated files, you'll need to do `make
distclean'.

Re: Building prog first

[Alfred M. Szmidt]

You say that the manuals are poor and that it is obvious, but I cannot
figure out from your explanation how they are poor.  I've looked at a
few manuals, glibc, emacs, coreutils, autoconf, and m4, and all of
them have good indices, are organised cleanly, etc.

Can you mention one or two manuals, and which part of those manuals
you find to be inadequate?

You mention that web access improves the manuals, how do they do that
exactly?  If you do a web search, then you will invariable end up at
the manual, no? 

If our manuals are not read and users think that reporting bugs,
improving them, is a waste of our time, then it would be better that
we remove them, since keeping them updated takes alot of time, more so
than actually improving our programs.  But users clearly need manuals,
as from your experience, and a bad manual is just as much a bug as
anything else in our programs.

Please don't think that improving a manual is any less of an
improvment than adding a very useful feature.

Re: Building prog first

[Alfred M. Szmidt]

   2010/3/22 Alfred M. Szmidt :
   > If searching is the problem

   *Web* searching is the answer, not the problem.

It isn't when you are not connected to a network.

   > how does the indices not fix the problem?

   I rarely find anything useful in the indices other than particular
   functions or variables. Rarely, in GNU manuals, concepts, but that is
   because they do not, on the whole, have good general indices.

Do you have a list of such manuals? Would you like to report this to
the relevant maintainers?  One cannot improve what one does not know
about.

   > What about using a info browser to search through the manual?

   I often do that. The trouble is that often what I want to know has to
   be deduced from the manual, which is natural enough, because the
   manual tends to be structured according to the structure of the
   program it documents, rather than of the problems the user is trying
   to solve. By using web searches I can often find people asking and
   answering precisely the problem I'm trying to solve.

Would youlike to suggest a better structuring for some manuals?

Re: Building prog first

[Alfred M. Szmidt]

If searching is the problem how does the indices not fix the problem?
What about using a info browser to search through the manual?

Re: Building prog first

[Alfred M. Szmidt]

Have you tried reading `(automake) Autotools Introduction'? It is part
of the automake manual.

Re: Building prog first

[Alfred M. Szmidt]

   However, "make install" installs unimain into /usr/local/bin

Please refer to the manual, it documents how to do that, and more.
You can try the chapter `(automake) Fine-grained Distribution
Control'.

Re: Sun compiler and /usr/local/include

[Alfred M. Szmidt]

   >   CPPFLAGS=-I/usr/local/include ./configure

   Bzzt.  Please pass variable settings as arguments to configure:
 ./configure CPPFLAGS=-I/usr/local/include

   not as environment variables.  It has the advantage that
 ./config.status --recheck

   (which may be triggered from a makefile) remembers such settings
   *even* if the variables in question are not marked as precious by
   configure.ac.  (CPPFLAGS is markes as precious by AC_PROG_CC, but
   better get the "new-since 10 years" way of doing it in your head
   now ;-)

True true! Sadly I encounter old programs that still don't grok this;
so it is kinda hardwired into my brain. :-(

Re: Sun compiler and /usr/local/include

[Alfred M. Szmidt]

   If the file is; /usr/local/include/package/header.h
   and source is;  #include 
   what goes in configure.ac?

You shouldn't put anything into configure.ac; if you wish to tell your
compiler where to find non-standard headers (i.e. anything the
compiler doesn't search by default) you should do so when calling
./configure, that is:

  CPPFLAGS=-I/usr/local/include ./configure

If you wish to make it system wide, you can use config.site, see
`(autoconf) Site Defaults' for details.

   Apologies for the footer. External mail is thoroughly blocked, and the 
   server adds the footer.

That can't really be the case, since your messages are being passed
through.

-- 
cryptographic BLU-114/B David John Oates eternity server SAFE Becker
fraud Manfurov 2600 Magazine White House JPL Ruby Ridge AFSPC event
security broadside Semtex MILSATCOM brigand S Box Ft. Meade AFSPC
Arnett PLO cypherpunk AUTODIN Rubin dictionary CISU Skipjack Aladdin

Re: silent installs

[Alfred M. Szmidt]

   > I was refering to AM_SILENT_RULES, which supresses `make all'
   > output; so this is not a very controversial topic, it is already
   > in automake and used by several projects.  Would you like to work
   > on this feature?  The maintainers can't accept a patch that
   > doesn't exist after all...

   I am afraid I not very handy with the program language skills
   needed for this. The best I can do is a small patch to ltmain.sh
   for the most trivial part. Getting rid of the install msgs is over
   my head.

You don't need that much programming skills to fix this, infact, all
the scaffolding is in place.  Take a look in automake/lib/am/progs.am
and automake/lib/am/script.am, and the %SILENT% macro; you'd need to
replace occurences of `echo' with a variable (since we cannot just use
@ to silence the rules), that expands to either : (though, I think
"INSTALL file" would be nicer than complete silence) or echo depending
on if are using V=0 or V=1.

   Index: ltmain.sh
   ===
   --- ltmain.sh(revision 57662)
   +++ ltmain.sh(working copy)
   @@ -2028,7 +2028,7 @@
   relink_command=`$ECHO "X$relink_command" | $Xsed -e 
"s...@inst_prefix_dir@%%"`
 fi

   -  func_warning "relinking \`$file'"
   +  $opt_silent || func_warning "relinking \`$file'"

The problem with this approach is that ltmain.sh is part of libtool,
and doen't inherit (as far as I remeber) and of the rule you pass to
automake/make.  So one would need to pass down something via automake
to libtool, which might get cumbersome. :-(

Also, you'd probobly want to put the check in func_warning anyway, that
way you'd silence all invocations of func_warning.

Sadly, I don't have the source here to whip up a patch; but it is a
easy patch that I'm confident you can do by yourself :-)

Re: silent installs

[Alfred M. Szmidt]

   On 01/29/2010 02:05 PM, Steffen Dettmer wrote:
   > On Fri, Jan 29, 2010 at 9:21 AM, Ralf Corsepius  
wrote:
   >> Silent make rules are harmful:
   >> - Bogus defines []
   >> typically do not show up as compiler warnings or errors.
   >
   > Could you please explain that?

   Example: Compling a package under linux

The system that you are refering to as `Linux' is really called GNU
and was started by the GNU projet in 1984, many people don't know the
GNU project and what it does.  You can help us spread that knowledge
by talking about GNU when you talk about GNU-powered software
distributions (a la GNU/Linux instead of just Linux).  See
http://www.gnu.org/gnu/linux-and-gnu.html for more details.

   configure --prefix=/usr 
   ...
   gcc -DCONFDIR="/foo/bar" -DIRIX ...

   Using silent make rules you will not notice the bogus -DCONFDIR at 
   compilation time. 

If these macros where put into a header file, which is the usual case,
they would not been seen either.  The whole argument that silent
output from make is `harmful' is really not true; very few people
actually read it and to help a user you will always want to ask for
config.log which give you all the required information; including any
compiler flags

   >> Silent building is only appropriate when a user knows what he is
   >> doing and when explicitly asking of it.
   >
   > typing "make -s" is explicitly asking, isn't it?

   With gnu make, yes. But is it portable to other makes?

Using the same system as for AM_SILENT_RULES (make V=0/1) then it
would be portable across make's.

Re: silent installs

[Alfred M. Szmidt]

   > And there are many examples of the opposite where less verbose
   > output is useful, automake already supports silent compilation.
   > I know that

   Yes, but automake --silent is a different tool, perhaps it should
   learn suppress the install mgs as well as other libtool msgs such
   as relinking as finish msgs?

I was refering to AM_SILENT_RULES, which supresses `make all' output;
so this is not a very controversial topic, it is already in automake
and used by several projects.  Would you like to work on this feature?
The maintainers can't accept a patch that doesn't exist after all...

Re: silent installs

[Alfred M. Szmidt]

And there are many examples of the opposite where less verbose output
is useful, automake already supports silent compilation.  I know that
I have missed errors or warnings beause having had to much output to
read, Joakim, would you like to work on a patch for this? I think it
would be immensly useful.

Re: ifdef in Makefile.am

[Alfred M. Szmidt]

   I basicall want to do in a Makefile.am
   ifdef automake version > 1.4
 AM_LDFLAGS=...
   else
 LDFLAGS=...
   endif
   Because am version == 1.4 does not like
   some newer automake macros and I am moving a big project over
   to am 1.10. I need the 2 versions to coexist for a while
   until I have moved everything over.
   How can I do this? Tried lots of variants but no luck.

Create a branch for this, or simply migrate everything to automake
1.10+ without supporting 1.4, since it is not worth the effort to do
so.

Re: Add missing bootstrap file

[Alfred M. Szmidt]

You didn't answer why you need this switch, only that you want it.

Re: Add missing bootstrap file

[Alfred M. Szmidt]

   Index: automake/m4/init.m4
   ===
   --- automake.orig/m4/init.m4
   +++ automake/m4/init.m4
   @@ -107,6 +107,7 @@ dnl is hooked onto _AC_COMPILER_EXEEXT e
AC_CONFIG_COMMANDS_PRE(dnl
[m4_provide_if([_AM_COMPILER_EXEEXT],
  [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
   +AM_SILENT_RULES([yes])
])

Why is this needed?  Maybe the problem can be solved in a better way.

Re: Asking for a tutorial to solve two different cases

[Alfred M. Szmidt]

   I'm developping an application. The question is that once installed
   I'd like to find it hanged to my Gnome general applications
   menu. For this, I'm searching the info about how should I configure
   the autotools files project.

   I'd like to take the opportunity to ask you also the same but in
   the case of a server. How should I do to update /etc/services,
   /etc/rc.Xd/, to transfer permissions...  ???

You shouldn't, those are configuration files, and are for the system
administrator to edit.

Re: improve INSTALL contents

[Alfred M. Szmidt]

   can you please also read, and follow
   ?
   I'm sure you must have missed it because I failed to spam it to
   three mailing lists.  But your repetitions are just as boring as
   those from everyone else.  And get bug-coreutils and automake off
   the recipients lists!

I do not see what point you are trying to make.  And please be more
polite in the future.

Re: improve INSTALL contents

[Alfred M. Szmidt]

   Indeed - I want to be very clear in INSTALL that there are some
   basics that pretty much any client of this file provide (make, make
   install), and some options that nice packages provide but which may
   fail if someone borrowed this file but does follow everything
   checked by automake's distcheck (whether or not they use automake).
   Would it be better to put the discussion of DESTDIR in the Optional
   Features node, alongside the discussion of --enable-silent-rules?
   Or do we just keep a disclaimer phrase in place, such as:

   Some packages support installation into a staging directory
   (e.g. for packaging or testing purposes), by setting the
   DESTDIR variable, as in @samp{make destd...@var{dir} install}.

Please not not hide this information in a seperate section.  A small
disclaimer like you purpose is a good middle ground, though I would
write `Most packages ...', since most packages do support DESTDIR.

I think we should try to make users more aware of DESTDIR, so that
they can report bugs for packages that do not support it.

Re: improve INSTALL contents

[Alfred M. Szmidt]

   >In addition, if you use an unusual directory layout you can give
   >options like @option{--bind...@var{dir}} to specify different
   >values for particular kinds of files.  Run @samp{configure --help}
   >for a list of the directories you can set and what kinds of files
   >go in them.  In general, the default for these options is expressed
   >in terms of @sam...@{prefix@}}, so that specifying just
   >@option{--prefix} will affect all of the other directory
   >specifications.
   >
   >If you wish to install the package into a staging directory
   >(e.g. for packaging or testing purposes) then you can set the
   >DESTDIR variable, @samp{make destd...@var{dir} install}.

   What about packages that don't support arbitrary prefix override
   (all those using current libtool),

I do not understand, DESTDIR is supported with libtool.

   or packages or systems that don't support DESTDIR installs?  This
   wording creates problems for them.

Then it should be reported to the maintainer(s) so that they can fix
the bug.

Re: improve INSTALL contents

[Alfred M. Szmidt]

   >> What about packages that don't support arbitrary prefix override
   >> (all those using current libtool), or packages or systems that
   >> don't support DESTDIR installs?  This wording creates problems
   >> for them.
   >
   > Indeed - I want to be very clear in INSTALL that there are some
   > basics that pretty much any client of this file provide (make,
   > make install), and some options that nice packages provide but
   > which may fail if someone borrowed this file but does follow
   > everything checked by automake's distcheck (whether or not they
   > use automake).  Would it be better to put

   What about the second part of Ralf's comment to the extent that
   some operating systems don't support DESTDIR installs?

Then that would be a bug in the package.

   A package may be very nicely prepared and pass 'make distcheck'
   under Linux yet not work as expected with DESTDIR on some other
   operating environment (presumably those which hard-code install
   paths, or for which libtool --mode=finish is really needed).

When one calls the GNU/Linux operatinig system for `Linux', one does a
disservice to the prinicpal developers of the GNU system since it
diminishes our efforts.  Could you please call the GNU system with
Linux for GNU/Linux, and help the GNU project in clearing up this
confusion?

Please see http://www.gnu.org/gnu/linux-and-gnu.html for more detailed
explanation.

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

[Alfred M. Szmidt]

How about this?  I took into account Ralf's comments as well.

   In addition, if you use an unusual directory layout you can give
   options like @option{--bind...@var{dir}} to specify different
   values for particular kinds of files.  Run @samp{configure --help}
   for a list of the directories you can set and what kinds of files
   go in them.  In general, the default for these options is expressed
   in terms of @sam...@{prefix@}}, so that specifying just
   @option{--prefix} will affect all of the other directory
   specifications.
   
   If you wish to install the package into a staging directory
   (e.g. for packaging or testing purposes) then you can set the
   DESTDIR variable, @samp{make destd...@var{dir} install}.

Re: improve INSTALL contents

[Alfred M. Szmidt]

   >+Depending on the package, the default directory layout chosen during
   >+...@command{configure} can be altered during subsequent execution of
   >+...@command{make}.  
   > 
   > A `make install FOO=VAL' should never alter anything in the build
   > directory.  The problem is if you pass --bindir=/foo to configure, and
   > then do `make install prefix=/bar', the files installed in bindir will
   > be installed in /foo, and not /bar as the user might have exepcted;
   > this is why passing prefix to `make install' is a bad idea.

   Agreed - which is why I went on to say this in the same paragraph:

   +However, some programs need to know at
   +compile time where files will be installed, so the user should ensure
   +that the same directory choice is made for both @samp{make all} and
   +...@samp{make install}.

   Any suggestions on how to improve the wording to make this point
   more explicit?

I will try to think of something--please give me a day or two, I don't
like the current wording since it indirectly contradicts the GCS, and
is very unclear.  

Thanks for mentioning V=0 and --disable-silent-rules, I didn't know
about that!

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

[Alfred M. Szmidt]

   +Depending on the package, the default directory layout chosen during
   +...@command{configure} can be altered during subsequent execution of
   +...@command{make}.  

A `make install FOO=VAL' should never alter anything in the build
directory.  The problem is if you pass --bindir=/foo to configure, and
then do `make install prefix=/bar', the files installed in bindir will
be installed in /foo, and not /bar as the user might have exepcted;
this is why passing prefix to `make install' is a bad idea.

Re: Core-utils 7.2; building only 'su'

[Alfred M. Szmidt]

   > 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.  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.

Re: Core-utils 7.2; building only 'su'

[Alfred M. Szmidt]

   >>Hmmm.  Would it be worth changing autoconf to make './configure
   >>--help' state something like the following:
   >> 
   >>| Some influential environment variables:
   >>|   ...
   >>|   DESTDIRleave unset during configure; allows installation to
   >>|  specify a staging area different than the final 
prefix

   Please, let's not bloat `configure --help' output even more.  It is
   already very long for a simple help text, it should not document
   things that are not, in fact, settings for configure but for the
   makefile.

I see no harm in mentioning it in the output for configure --help, the
output is not _that_ long.

| By default, `make install' will install all the files in
| `/usr/local/bin', `/usr/local/lib' etc.  You can specify
| an installation prefix other than `/usr/local' using `--prefix',
| for instance `--prefix=$HOME'.

We already mention `make install' in the output, so it would make
sense to add a single line to this sentence.  Maybe the sentence that
Eric suggested.

   >Not all packages follow GNU Coding Standards, therefore, DESTDIR is not
   >properly supported in a surprisingly large number of packages.
   > 
   > We already enforce a level of GNUism on packages that use
   > autoconf/automake, I do not think it would be the end of the world if
   > we did it in this case as well.

   This case is different.  DESTDIR has the important drawback that it
   does not work well with w32-style installation directory names like
   `C:/foo', because you cannot prepend to such a path.  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"?

What is the problem with DESTDIR=C:/foo?

   >> I do not think that users are confused about passing DESTDIR
   >> during configure time either.  DESTDIR is and has always
   >> been a automake variable.  Alas, the only useful place to
   >> put this information is in the output of --help.  Maybe
   >> something more like this would be a bit more suitable (not
   >> to happy about the actual wording):
   >> 
   >> `To install FOO in a different directory for the purpose of
   >> making a tarball, or similar pass DESTDIR to `make install''
   > 
   >Maybe the shorter:
   > 
   >`To install FOO in a staging directory, use `make install
   >DESTDIR=...''
   > 
   > I like that.

   However, this text may not be added by Autoconf as Autoconf cannot
   be sure that the package supports this.  Pedantically, the package
   cannot even be sure that `make' is used at all.  IMVHO the right
   place to document DESTDIR is along with documentation to the
   standard make targets.  INSTALL documents a couple, but would grow
   too large if it documented all (and is also targeted at
   non-automake-using packages).

The output from configure already mentions things that it cannot be
sure of, so I do not see the problem.  A project can easily ignore the
fact that --libexecdir is for daemons, and use sbindir or something
similar, or simply not use `make install' which configure --help
reports as something that is supported.

   Maybe the generic INSTALL file should provide pointers to more
   comprehensive documentation?

Making users have to hunt and pek to find all informaation is a bad
idea IHMO.

Re: Core-utils 7.2; building only 'su'

[Alfred M. Szmidt]

   > I tend to agree that INSTALL should either mention DESTDIR (and
   > probably also V, which now plays a role with new enough
   > automake), or at least point to the GNU Coding Standards and the
   > Automake manual overview of the GNU build system.  Does anyone
   > want to beat me to a patch?

   The problem is that DESTDIR is not a mandatory standard and
   packages may not adequately implement it even if Automake itself
   does the right thing.  If INSTALL says that DESTDIR is supported
   and a package blindly includes the INSTALL file, then package users
   may end up with a very unpleasant surprise (e.g. damaged operating
   system) if the package misbehaves with DESTDIR.

This is already the case for INSTALL.  For example, `make uninstall'
is often broken in many packages.  Same for --program-prefix.

The INSTALL file is probobly the best place to document this.

Re: Core-utils 7.2; building only 'su'

[Alfred M. Szmidt]

   >packages where DESTDIR doesn't work properly.  But automake
   >already does such a good job at providing DESTDIR support
   >(especially if the user remembered to run 'make distcheck'),
   >that I think it would be nice if using AM_INIT_AUTOMAKE did
   >make the ./configure --help mention the future effect of
   >DESTDIR.
   > 
   > I agree.  Does distcheck actually test DESTDIR?

   Absolutely, along with proper VPATH builds; two aspects that many
   non-automake packages get horribly wrong.
   
http://www.gnu.org/software/automake/manual/automake.html#Preparing-Distributions

Lovley! I suppose I just do things right from the start, and have
never noticed this!

Re: Core-utils 7.2; building only 'su'

[Alfred M. Szmidt]

   >Hmmm.  Would it be worth changing autoconf to make './configure
   >--help' state something like the following:
   > 
   >| Some influential environment variables:
   >|   ...
   >|   DESTDIRleave unset during configure; allows installation to
   >|  specify a staging area different than the final prefix
   > 
   >Perhaps even issue a warning if DESTDIR is set during configure
   >time?  Or would this proposal just cause more problems?
   > 
   > I know that the wording is only a suggestion, but I see multiple
   > problems.
   > 
   > DESTDIR is not synonymous with prefix, it is prepended to each of the
   > variables (exec_prefix, prefix, bindir, libexecdir, ...)  when they
   > are used as a destination during `make install'.

   Not all packages follow GNU Coding Standards, therefore, DESTDIR is not
   properly supported in a surprisingly large number of packages.

We already enforce a level of GNUism on packages that use
autoconf/automake, I do not think it would be the end of the world if
we did it in this case as well.

   > I do not think that users are confused about passing DESTDIR
   > during configure time either.  DESTDIR is and has always been a
   > automake variable.  Alas, the only useful place to put this
   > information is in the output of --help.  Maybe something more
   > like this would be a bit more suitable (not to happy about the
   > actual wording):
   > 
   > `To install FOO in a different directory for the purpose of
   > making a tarball, or similar pass DESTDIR to `make install''

   Maybe the shorter:

   `To install FOO in a staging directory, use `make install DESTDIR=...''

I like that.

   > Problem with the above, is that it only works when using make, but
   > maybe this is not a real problem?  If one uses AM_INIT in configure,
   > then the above could pop up...

   You have a point there - since autoconf cannot enforce the
   package's compliance of the GNU Coding Standards in its Makefile,
   it would not be good for autoconf to add this warning for the
   packages where DESTDIR doesn't work properly.  But automake already
   does such a good job at providing DESTDIR support (especially if
   the user remembered to run 'make distcheck'), that I think it would
   be nice if using AM_INIT_AUTOMAKE did make the ./configure --help
   mention the future effect of DESTDIR.

I agree.  Does distcheck actually test DESTDIR?