Re: Error when using make distcheck

[Roger Leigh]

On Wed, Nov 20, 2013 at 09:05:57AM +1000, Peter Johansson wrote:
> On 11/20/2013 06:45 AM, jerome hamm wrote:
> >Hi,
> >
> >I am trying to pack some software using udev rules, which therefore needs
> >to copy some files to /lib/udev/rules.d.
> >When I try and run make distcheck, at the step where it must  install the
> >files in /lib/udev/rules.d it hopelessly fails because of permission issues.
> >
> >My rules (leeched from  the upower project) are the following:
> ><Makefile.am>
> >udevrules_DATA = \
> >95-evvgc.rules
> ><configure.ac>
> ># UDEV for device permission acces setting
> >AC_ARG_WITH([udevrulesdir],
> >             AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev
> >rules]),
> >             [],
> >             [with_udevrulesdir=$($PKG_CONFIG --variable=udevdir
> >udev)"/rules.d"])
> >AC_SUBST([udevrulesdir], [$with_udevrulesdir])
> >
> >Someone in the #autotools channel told that it should try to copy the files
> >in a subfolder of the test folder (not the system root).
> >What I also don't understand is why it doesn't work when I try fakeroot
> >make distcheck ...
> >What am I doing wrong?
> 
> This sounds more like a question for the automake folks, but have
> you read this section in the Automake manual:
> 
> http://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths

This has been a bug in automake since forever, and a source of massive
frustration.  The fix (to automake) is also very simple.

The assumption automake makes is that everything you want to install
will go under the configured prefix.  While this is a nice ideal,
reality isn't so simple.  Examples:
- udev rules (as above)
- pam configuration (similar)
- nss modules
- any third party loadable modules/plugins
- cups printer drivers

All of the above have a common theme.  The software is installed into the
configured prefix, but it also needs to integrate with other software
which is /already installed into a different prefix/.  If I install it
into my prefix then the other software won't be able to make use of it.
Example: udev isn't going to look in /opt/mypackage/lib/udev/rules.d;
it does need installing to /lib/udev/rules.d.

automake supports this just fine.  It's even already happening outside
this special case if you configure with /usr as the prefix with
/etc as sysconfdir--it's installing outside the prefix.  What's broken
is just "distcheck"; if it set DESTDIR then it would work just fine.
As it is, it overrides prefix in a broken way, causing the above
problems.

In your specific case, because it overrides prefix, and you're not
using prefix in your install path, it still tries to use the full
path.  If it used DESTDIR correctly, it would be able to install it
into a staging directory without trouble.

I've now encountered this in a number of projects, for all of the above
example reasons.  In all cases the project built and distributed fine
but failed distcheck, and our only choice was to not use distcheck.
I've brought the issue up on this list a couple of times, and both times
I was told that what I was doing wasn't supported and was buggy.  BUT...
the important point here is that automake is clearly not supporting the
above use cases, so is falling short of the real needs of many projects.
Can't we just fix distcheck to use DESTDIR when doing the test install
and move on?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800