Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
[[[ 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
* 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
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
> 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
bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
- 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: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
- 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.
bug#8881: config.h double inclusion
I think that autoconf should have the guard for double inclusion. Autoconf does not need to provide a double-inclusion guard for config.h, because those packages that need it can get it through use of AH_TOP and AH_BOTTOM. That is not a reason to not include such a guard.
bug#8881: config.h double inclusion
I'm thinking that maybe config.h should be generated with a double inclusion guard But the general rule is that config.h must always be included first, no? So there shouldn't ever be a possibility of including it twice. Right, which is the case in inetutils in all places where we use config.h. The problem pops up when you have another header file that includes config.h (as the first thing) to use macros from it (for libinetutils.h it is PACKAGE_BUGREPORT and HAVE_FORK or something). It might be better to have config.h do something like this: #ifdef CONFIG_H # error config.h included twice #endif #define CONFIG_H Not against it, but I think that: #include config.h #include argp.h /* or some other gnulib header... */ #include config.h /* via some internal #include; where it is the first line */ should be valid to do. A bit later, we do: #include libinetutils.h which will cause warnings like: ../config.h:561:1: warning HAVE_DECL_PROGRAM_INVOCATION_NAME redefined Sp libinetutils.h includes config.h? Then that is a problem. One possible fix is to arrange for libinetutils.h to be built from libinetutils.in.h, the same way that (for example) stdint.h is built from stdint.in.h in gnulib. Right, sorry if I wasn't clear. I would prefer not to, the fix that I might go for if we can't fix this in autoconf would be: to simply do: #ifndef HAVE_CONFIG_H #error config.h hasn't been included; please include it #endif But I think that autoconf should have the guard for double inclusion.
bug#8881: config.h double inclusion
I'm thinking that maybe config.h should be generated with a double inclusion guard But the general rule is that config.h must always be included first, no? So there shouldn't ever be a possibility of including it twice. It might be better to have config.h do something like this: #ifdef CONFIG_H # error config.h included twice #endif #define CONFIG_H Warning: Quite a few misbehaving packages actually install their config.h. One should send bug reports for those cases, since it is just broken.
Re: default -g ??!?
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
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
� �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
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
2010/3/22 Alfred M. Szmidt a...@gnu.org: 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
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
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
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: Building prog first
Have you tried reading `(automake) Autotools Introduction'? It is part of the automake manual.
Re: Sun compiler and /usr/local/include
If the file is; /usr/local/include/package/header.h and source is; #include package/header.h 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: Sun compiler and /usr/local/include
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: silent installs
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: silent installs
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
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: ifdef in Makefile.am
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
You didn't answer why you need this switch, only that you want it.
Re: Add missing bootstrap file
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: improve INSTALL contents
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
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
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
can you please also read, and follow http://lists.gnu.org/archive/html/autoconf/2009-05/msg00058.html? 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 (was: Core-utils 7.2; building only 'su')
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 (was: Core-utils 7.2; building only 'su')
+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'
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'
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'
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'
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?
