Re: make distcheck fail due to unset DESTDIR

[Roger Leigh]

On Sat, Feb 28, 2009 at 03:38:42PM +0100, Ralf Wildenhues wrote:
> * Roger Leigh wrote on Sat, Feb 28, 2009 at 03:14:27PM CET:
> > pg_contrib_DATA =                   \
> >     debversion.sql                  \
> >     uninstall_debversion.sql
> 
> > However, "make distcheck" fails, with:
> > 
> > make[3]: Entering directory `/home/rleigh/sbuild/sbuild-0.58.0/_build/db'
> > make[3]: Nothing to be done for `install-exec-am'.
> > test -z "/usr/share/postgresql/8.3/contrib" || /bin/mkdir -p 
> > "/usr/share/postgresql/8.3/contrib"
> >  /usr/bin/install -c -m 644 'debversion.sql' 
> > '/usr/share/postgresql/8.3/contrib/debversion.sql'
> > /usr/bin/install: cannot create regular file 
> > `/usr/share/postgresql/8.3/contrib/debversion.sql': Permission denied
> >  /usr/bin/install -c -m 644 '../../db/uninstall_debversion.sql' 
> > '/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql'
> > /usr/bin/install: cannot create regular file 
> > `/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql': Permission 
> > denied
> 
> > The full source is at:
> > http://nagini.codelibre.net/~rleigh/sbuild-0.58.0.tar.gz
> 
> The problem is likely this code in configure.ac:
>   AC_MSG_CHECKING([for PostgreSQL architecture-independent support files 
> directory])
>   pg_server_sharedir=`"$PG_CONFIG" --sharedir`
>   AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQL 
> architecture-independent support files directory])],
>                 [pg_server_sharedir="${withval}"])
>   AC_MSG_RESULT([$pg_server_sharedir])
>   AC_SUBST([pg_server_sharedir])
> 
>   pg_contribdir="$pg_server_sharedir/contrib"
>   AC_SUBST([pg_contribdir])
> 
> Why?  Apart from a DESTDIR install, distcheck also tries to configure
> and install the tree below some specific --prefix, and tries to ensure
> that your package installs all files below $prefix.  This is a
> requirement from the GNU Coding Standards.  See here for more
> information:

Thanks.  I remembered after I sent the mail that I'd actually come across
this limitation before, and I think brought it up on the list.

While I do agree that the GNU coding standards are correct in insisting
that all files are installed under $prefix, I do think that there are
valid situations where this ideal scenario does not make sense.

For example: gutenprint provides CUPS printer drivers (backends), which
*must* be installed under $(cups-config --serverbin) [/usr/lib/cups on
my system].  Installing under /prefix would be possible, but would be
completely useless (the CUPS server looks in one location only for
available backends).  Currently, we do allow the user to override the
extra-prefix default location, so user installation is possible, but
not the default.

In this case, we are installing a PostgreSQL database extension, which
really needs the loadable modules installing in $(pg_config --pkglibdir)
[/usr/lib/postgresql/8.3/lib] on my system.  This is by default the only
path searched for extensions, though it is possible to add alternative
locations.

I guess my point here is that for some packages, user installation is
simply not possible (at least for some components of the package).
For others, it is possible, but not ideal.  I'm not sure exactly the
best way to default things in the configure script in the latter case.
Defaulting to strict GNU coding standards correctness isn't going to
be what most people would want.

Would it be possible to use *both* --prefix and $(DESTDIR) when
testing "make install" within "make distcheck"?  This would provide
several advantages:

1) The installation won't just fail if it attempts to install into
   a location outside $prefix.  If the location *had* been writable,
   it would still have succeeded had I run distcheck as root, for
   example, so *success doesn't guarantee a non-buggy package*.
   The uninstall check could even have removed files from the
   system AFAICT.

2) You can now check $prefix inside the DESTDIR, and also look at
   files installed outside $prefix but which are present in the
   DESTDIR and report these as buggy to the user and error out,
   which would help bring buggy Makefile.ams to the developer's
   attention.  This isn't currently done.  It would also allow one
   to add an automake option to not treat these files outside the
   prefix as errors.

This would both make distcheck both more robust, and more flexible.
While for all but a few packages installing outside $prefix is
completely wrong, I think that it would be nice it automake
had the flexibility to allow it if given the option, but obviously
not the default!

> One way to fix your code would be to check for whether the user has
> overridden $prefix, $datarootdir, or $datadir, and in that case, let
> pg_server_sharedir depend on the latter (the defaults for these
> variables are NONE, '${prefix}/share', and '${datarootdir}',
> respectively, with recent Autoconf versions).  Another way to let
> the distcheck pass (but still allow to annoy your users ;-)
> is to add an appropriate --with-pg-server-sharedir to the make macro
> DISTCHECK_CONFIGURE_FLAGS.

The latter choice would make sense.  We already allow the user to
override all these settings, so if the do want them under $prefix,
it's possible.

> BTW, in above code, there are a couple of trivial issues: this
>   AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQL 
> architecture-independent support files directory])],
>                 [pg_server_sharedir="${withval}"])
> 
> should likely be something like:
>   AC_ARG_ENABLE([pg-server-sharedir],

OK, thanks.  Is enable appropriate here rather than wide?  It's
slightly ambiguous as to whether this is working with external
software or a feature to enable (since it's sort of both).


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

signature.asc
Description: Digital signature