[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make distcheck fail due to unset DESTDIR

From: Ralf Wildenhues
Subject: Re: make distcheck fail due to unset DESTDIR
Date: Sat, 28 Feb 2009 18:34:07 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

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


> 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

> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]