Re: make distcheck fail due to unset DESTDIR
* Roger Leigh wrote on Sat, Feb 28, 2009 at 06:10:11PM CET:
> On Sat, Feb 28, 2009 at 03:38:42PM +0100, Ralf Wildenhues wrote:
> > 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:
> 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.
And I agree. But I think that we can have both!
> 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.
OK.
> I guess my point here is that for some packages, user installation is
> simply not possible (at least for some components of the package).
Well, one autotool principle is "the user may be smarter than the
package developer". While on all setups you're aware of, user
installation isn't possible, some user may be smart enough to hack
up her system to allow for it. Not limiting that user is a worthy
goal.
> 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.
Well, you don't need the *default* to be using $datadir. At least not
when neither --prefix, --datarootdir, nor --datadir have been used.
> Would it be possible to use *both* --prefix and $(DESTDIR) when
> testing "make install" within "make distcheck"?
This kind of testing is *also* done during the course of distcheck.
> 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.
Hmm, a couple of notes: first, I for one wouldn't ever run distcheck as
root unless the package passed distcheck as unprivileged user and I had
rather closely inspected it. Second, the part of distcheck that tests a
DESTDIR install does make the $prefix non-writable, so it should catch
such a buggy package, at least when distcheck is run as an unprivileged
user.
> 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.
Yes, I suppose we could do this. I can only guess that it hasn't been
done before because it may not be so uncommon to install outside of
$prefix (e.g. /etc).
> 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!
If you want to submit a patch, be sure to read the HACKING file in the
git repo of Automake.
> > 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).
Oh. I wasn't aware of that. Again, the GCS lists the criteria:
but some choices just are sort of both, and in that case, it's
good to stick to what you prefer or other packages do in the same
case, I guess.
Cheers,
Ralf
Re: make distcheck fail due to unset DESTDIR
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 use
Re: make distcheck fail due to unset DESTDIR
* 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:
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.
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],
[AS_HELP_STRING([--enable-pg-server-sharedir],
[PostgreSQL architecture-independent support files directory])],
[pg_server_sharedir="${enableval}"])
no?
Hope that helps.
Cheers,
Ralf
make distcheck fail due to unset DESTDIR
Hi folks, In a Makefile.am, I have the following: -- if BUILD_DEBVERSION pg_server_lib_LTLIBRARIES = \ debversion.la debversion_la_SOURCES = \ debversion.cc debversion_la_CXXFLAGS = -I$(pg_server_includedir) debversion_la_LDFLAGS = -module -avoid-version $(APT_PKG_LIBS) pg_contrib_DATA = \ debversion.sql \ uninstall_debversion.sql endif debversion.sql: debversion.sql.in sed 's,MODULE_PATHNAME,$$libdir/$*,g' $< >$@ 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 rule itself looks OK: install-pg_contribDATA: $(pg_contrib_DATA) @$(NORMAL_INSTALL) test -z "$(pg_contribdir)" || $(MKDIR_P) "$(DESTDIR)$(pg_contribdir)" @list='$(pg_contrib_DATA)'; for p in $$list; do \ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ f=$(am__strip_dir) \ echo " $(pg_contribDATA_INSTALL) '$$d$$p' '$(DESTDIR)$(pg_contribdir)/$$f'"; \ $(pg_contribDATA_INSTALL) "$$d$$p" "$(DESTDIR)$(pg_contribdir)/$$f"; \ done It contains DESTDIR, and DESTDIR is set in the top-level Makefile in the distcheck rule. So I'm not sure where the cause of this failure lies-- I can't see anything obvious in the Makefile.am. I tried removing the automake conditional in case that screwed things up subtly, but it makes no difference. I'm using automake-1.10.1 on Debian GNU/Linux. The full source is at: http://nagini.codelibre.net/~rleigh/sbuild-0.58.0.tar.gz (db/Makefile.am is the Makefile in question.) 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
