GNU bug report logs - #10791
aclocal fails if /usr/share/aclocal does not exist

Previous Next

Package: automake;

Reported by: Tim Retout <diocles <at> debian.org>

Date: Sat, 11 Feb 2012 19:40:02 UTC

Severity: normal

Tags: notabug

Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10791 in the body.
You can then email your comments to 10791 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Sat, 11 Feb 2012 19:40:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Retout <diocles <at> debian.org>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Sat, 11 Feb 2012 19:40:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tim Retout <diocles <at> debian.org>
To: bug-automake <at> gnu.org
Subject: aclocal fails if /usr/share/aclocal does not exist
Date: Sat, 11 Feb 2012 19:19:58 +0000
[ Reposted from the Debian BTS: http://bugs.debian.org/659482 ]

Since automake 1.11.2, aclocal no longer succeeds if the system acdir
does not exist.  This causes Debian's 'make' package (and possibly
others?) to FTBFS under cowbuilder, because it calls autoreconf when
/usr/share/aclocal is not present.

Code removed as part of upstream commit 30f99cb:

-  if (! -d $system_includes[0])
-    {
-      # By default $(datadir)/aclocal doesn't exist.  We don't want to
-      # get an error in the case where we are searching the default
-      # directory and it hasn't been created.  (We know
-      # @system_includes has its default value if @automake_includes
-      # is not empty, because --acdir is the only way to change this.)
-      @system_includes = () if @automake_includes;

Checking @automake_includes is not appropriate any more, but I think
@system_includes should still be made empty if the default directory
does not exist.

-- 
Tim Retout <diocles <at> debian.org>




Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Tue, 21 Feb 2012 22:39:01 GMT) Full text and rfc822 format available.

Message #8 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Tim Retout <diocles <at> debian.org>
Cc: 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Tue, 21 Feb 2012 23:35:53 +0100
Hi Tim, sorry for the delay.

On 02/11/2012 08:19 PM, Tim Retout wrote:
> [ Reposted from the Debian BTS: http://bugs.debian.org/659482 ]
> 
> Since automake 1.11.2, aclocal no longer succeeds if the system acdir
> does not exist.  This causes Debian's 'make' package (and possibly
> others?) to FTBFS under cowbuilder, because it calls autoreconf when
> /usr/share/aclocal is not present.
>
But the automake build system creates /usr/share/aclocal at "make install"
time...  So, how comes that this "cowbuilder" provides an aclocal program
without an /usr/share/aclocal directory?

Sorry, but I regard that as a broken aclocal installation, and not for a
fault of the automake build system; so I'm inclined to label this report
as "notabug" and close it.  Still, I'll wait a couple of days before doing
so, in case I've missed something or you want to provide more rationale
for your request.

Thanks,
  Stefano




Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Tue, 21 Feb 2012 23:35:01 GMT) Full text and rfc822 format available.

Message #11 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Tim Retout <diocles <at> debian.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Tue, 21 Feb 2012 23:32:03 +0000
Hi Stefano!

On 21 February 2012 22:35, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> On 02/11/2012 08:19 PM, Tim Retout wrote:
>> Since automake 1.11.2, aclocal no longer succeeds if the system acdir
>> does not exist.  This causes Debian's 'make' package (and possibly
>> others?) to FTBFS under cowbuilder, because it calls autoreconf when
>> /usr/share/aclocal is not present.
>>
> But the automake build system creates /usr/share/aclocal at "make install"
> time...  So, how comes that this "cowbuilder" provides an aclocal program
> without an /usr/share/aclocal directory?

Well, /usr/share/aclocal-1.11 exists.  But /usr/share/aclocal does
not, because there are no third-party m4 files required at the time
that GNU Make was being compiled.

Cowbuilder is a minimal chroot environment designed to ensure clean
builds - it is very common for packages to be built in this type of
environment, and it worked all the way up to and including automake
1.11.1.

Should automake installations create an empty /usr/share/aclocal
directory?  That might be all that's needed to fix this.  I notice
that m4/Makefile.am has a relatively new comment about creating
$(system_acdir)... the Debian packaging probably hasn't been updated
to reflect this.

So, I think I've answered my own question - we can fix this in the
packaging.  :)  I don't *think* multiple automake versions on the same
system owning /usr/share/aclocal will be a problem...

Kind regards,

-- 
Tim Retout <diocles <at> debian.org>




Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Wed, 22 Feb 2012 08:30:02 GMT) Full text and rfc822 format available.

Message #14 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Tim Retout <diocles <at> debian.org>
Cc: 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Wed, 22 Feb 2012 09:26:25 +0100
On 02/22/2012 12:32 AM, Tim Retout wrote:
> Hi Stefano!
> 
> On 21 February 2012 22:35, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
>> On 02/11/2012 08:19 PM, Tim Retout wrote:
>>> Since automake 1.11.2, aclocal no longer succeeds if the system acdir
>>> does not exist.  This causes Debian's 'make' package (and possibly
>>> others?) to FTBFS under cowbuilder, because it calls autoreconf when
>>> /usr/share/aclocal is not present.
>>>
>> But the automake build system creates /usr/share/aclocal at "make install"
>> time...  So, how comes that this "cowbuilder" provides an aclocal program
>> without an /usr/share/aclocal directory?
> 
> Well, /usr/share/aclocal-1.11 exists.
>
Yes, but that's the "versioned acdir" a.k.a. "automake acdir" (where the
.m4 files defining automake-provided m4 macros like AM_INIT_AUTOMAKE are
installed), *not* the "system acdir" (where third-party system-wide .m4
files are expected to be installed).

The main difference among these two directories, installation-wise, is
that the versioned acdir is created with actual contents from the start,
while the system acdir is created empty, and possibly filled later by
installation third-party packages, like, say, pkg-config or gettext:

  $ dpkg -L pkg-config | grep '\.m4$'
  /usr/share/aclocal/pkg.m4

  $ dpkg -L gettext | grep '\.m4$' | head -2
  /usr/share/aclocal/size_max.m4
  /usr/share/aclocal/codeset.m4

> But /usr/share/aclocal does not, because there are no third-party
> m4 files required at the time that GNU Make was being compiled.
>
Weird; the directory is created unconditionally by automake's
"make install".  Might it be the fault of cowbuilder that it somehow
removes empty directories when creating its chroot environment?

> Cowbuilder is a minimal chroot environment designed to ensure clean
> builds - it is very common for packages to be built in this type of
> environment, and it worked all the way up to and including automake
> 1.11.1.
> 
> Should automake installations create an empty /usr/share/aclocal
> directory?
>
They do (otherwise aclocal would be broken out-of-the box):

  $ cd  ~/src/am
  $ ./configure --prefix=`pwd`/i && make install
  ...
  $ ls -l i/share
  total 24
  drwxr-xr-x 2 stefano stefano 4096 Feb 22 09:22 aclocal
  drwxr-xr-x 2 stefano stefano 4096 Feb 22 09:22 aclocal-1.11a
  drwxr-xr-x 4 stefano stefano 4096 Feb 22 09:22 automake-1.11a
  ...

> That might be all that's needed to fix this.  I notice that
> m4/Makefile.am has a relatively new comment about creating
> $(system_acdir)...
>
But that comments says that it is automake's "make install" that
should create it ;-)

> the Debian packaging probably hasn't been updated to reflect this.
> 
> So, I think I've answered my own question - we can fix this in the
> packaging.  :)  I don't *think* multiple automake versions on the same
> system owning /usr/share/aclocal will be a problem...
>
It shouldn't -- /usr/share/aclocal is meant to be shared

> Kind regards,
> 

Thanks,
  Stefano




Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Wed, 22 Feb 2012 09:17:02 GMT) Full text and rfc822 format available.

Message #17 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Tim Retout <diocles <at> debian.org>
Cc: 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Wed, 22 Feb 2012 10:14:18 +0100
[Message part 1 (text/plain, inline)]
On 02/22/2012 09:26 AM, Stefano Lattarini wrote:
>
>> But /usr/share/aclocal does not, because there are no third-party
>> m4 files required at the time that GNU Make was being compiled.
>>
> Weird; the directory is created unconditionally by automake's
> "make install".  Might it be the fault of cowbuilder that it somehow
> removes empty directories when creating its chroot environment?
> 
If this is the case, it might be worth applying the attached patch...

Regards,
  Stefano
[0001-aclocal-don-t-create-usr-share-aclocal-as-empty.patch (text/x-diff, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Wed, 22 Feb 2012 09:28:01 GMT) Full text and rfc822 format available.

Message #20 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Tim Retout <diocles <at> debian.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Wed, 22 Feb 2012 09:25:08 +0000
On 22 February 2012 08:26, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
>> But /usr/share/aclocal does not, because there are no third-party
>> m4 files required at the time that GNU Make was being compiled.
>>
> Weird; the directory is created unconditionally by automake's
> "make install".

Yes, but this is new, so the Debian automake packaging (as it
currently stands) doesn't install that directory.  Cowbuilder won't
remove empty directories.

Adding a README file will cause us problems if automake-1.11 and
automake-1.12 (say) are installed on the same system - who owns the
README?  So I think we'll agree to just fix Debian's automake package.

Thanks for your help. :)

-- 
Tim Retout <diocles <at> debian.org>




Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Wed, 22 Feb 2012 09:33:01 GMT) Full text and rfc822 format available.

Message #23 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Tim Retout <diocles <at> debian.org>
Cc: 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Wed, 22 Feb 2012 10:30:18 +0100
tags 10791 notabug
close 10791
thanks

On 02/22/2012 10:25 AM, Tim Retout wrote:
> On 22 February 2012 08:26, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
>>> But /usr/share/aclocal does not, because there are no third-party
>>> m4 files required at the time that GNU Make was being compiled.
>>>
>> Weird; the directory is created unconditionally by automake's
>> "make install".
> 
> Yes, but this is new, so the Debian automake packaging (as it
> currently stands) doesn't install that directory.  Cowbuilder won't
> remove empty directories.
>
Ah, OK, thanks for the info.

> Adding a README file will cause us problems if automake-1.11 and
> automake-1.12 (say) are installed on the same system - who owns the
> README?
>
Good point.  Let's just drop my patch for now.

> So I think we'll agree to just fix Debian's automake package.
>
Nice! :-)

Regards,
  Stefano




Added tag(s) notabug. Request was from Stefano Lattarini <stefano.lattarini <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 22 Feb 2012 09:33:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 10791 <at> debbugs.gnu.org and Tim Retout <diocles <at> debian.org> Request was from Stefano Lattarini <stefano.lattarini <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 22 Feb 2012 09:33:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Sun, 26 Feb 2012 10:05:02 GMT) Full text and rfc822 format available.

Message #30 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Tim Retout <diocles <at> debian.org>
Cc: automake-patches <at> gnu.org, 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Sun, 26 Feb 2012 11:01:39 +0100
[Message part 1 (text/plain, inline)]
On 02/22/2012 10:30 AM, Stefano Lattarini wrote:
>
> On 02/22/2012 10:25 AM, Tim Retout wrote:
> 
>> Adding a README file will cause us problems if automake-1.11 and
>> automake-1.12 (say) are installed on the same system - who owns the
>> README?
>>
> Good point.  Let's just drop my patch for now.
> 
But the more I think about it, the more I dislike the idea of creating
an empty directory whose existence is required by aclocal in order for
it to function at all.  Moreover, the objection you've raised might be
applied to the aclocal and automake (unversioned) scripts themselves,
but that doesn't prevent us from installing them.

So I've committed the patch after all (see attachment).

Regards,
  Stefano
[0001-aclocal-don-t-create-usr-share-aclocal-as-empty.patch (text/x-diff, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#10791; Package automake. (Mon, 27 Feb 2012 09:14:01 GMT) Full text and rfc822 format available.

Message #33 received at 10791 <at> debbugs.gnu.org (full text, mbox):

From: Tim Retout <diocles <at> debian.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: automake-patches <at> gnu.org, 10791 <at> debbugs.gnu.org
Subject: Re: bug#10791: aclocal fails if /usr/share/aclocal does not exist
Date: Mon, 27 Feb 2012 09:10:47 +0000
On 26 February 2012 10:01, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> But the more I think about it, the more I dislike the idea of creating
> an empty directory whose existence is required by aclocal in order for
> it to function at all.  Moreover, the objection you've raised might be
> applied to the aclocal and automake (unversioned) scripts themselves,
> but that doesn't prevent us from installing them.

It's your prerogative to apply the patch, but I disagree with your
reasoning here.  If you don't like empty directories being required,
go back to the old automake 1.11.1 behaviour where aclocal handled it
properly.

The mechanisms that Debian uses to handle unversioned aclocal and
automake are not appropriate for a README file.  I suspect it will end
up not being installed.  And that will mean unnecessary divergence
from upstream, which I don't like to see. :(

-- 
Tim Retout <diocles <at> debian.org>




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 26 Mar 2012 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 13 years and 146 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.