From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeff Garzik <jeff@garzik.org>
Subject: Re: AC_CONFIG_MACRO_DIR([m4])
Date: Mon, 06 Dec 2010 13:56:37 -0500
Message-ID: <4CFD31E5.2090508@garzik.org>
References: <20101205145655.4f91e5d6@lembas.zaitcev.lan> <4CFD1E26.8010908@garzik.org> <20101206104419.5a7205e5@lembas.zaitcev.lan>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <hail-devel-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:sender:message-id:date:from
         :user-agent:mime-version:to:cc:subject:references:in-reply-to
         :content-type:content-transfer-encoding;
        bh=QVH75wa+Ncw7k8Hh2s3MCGbpn+gUsJWVs4aXvfrinFM=;
        b=KgeRNjaRw0gskkFnpLgV2pqUiJ2tyjuQ2yU4ht7SFQwhQgLpGALH6P1EPc+bmSDl8u
         5FtcFui+GnHhg2kSU1t4uiSh0rhCl/bF7uXHf9sS7FiRz8bdfAbb4iW6gQWRvlPF5FYA
         TkT+8TBq5qqpO4v+1Q5EF30g21yEV+r2t1Kds=
In-Reply-To: <20101206104419.5a7205e5@lembas.zaitcev.lan>
Sender: hail-devel-owner@vger.kernel.org
List-ID: <hail-devel.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: Jim Meyering <jim@meyering.net>, hail-devel@vger.kernel.org

On 12/06/2010 12:44 PM, Pete Zaitcev wrote:
> On Mon, 06 Dec 2010 12:32:22 -0500
> Jeff Garzik<jeff@garzik.org>  wrote:
>
>> Keeping the "correct libtool macros in-tree" implies adding a pointless
>> maintenance burden.  The distro always gives us correct, up-to-date
>> files.  Why would hail want to potentially lag upstream's version of
>> these macros, forcing us to manually track macros that are currently
>> updated automatically for each ./autogen.sh invocation?
>
> I presumed that the important part is a compatibility between the
> syntax used in various .am files and the libtool scriptography that
> underpins them. "Lagging" upstream has no downside in this case
> (unlike zlib, where security fixes may exist).

It does not seem optimal to run a current libtool with outdated macro 
files.  In all cases except current one, you're checking in third party, 
maintained, versioned files to hail.git where they will be less-well 
maintained, and generally out-of-date vis a vis current [upstream | Fedora].

Where is the value in performing this additional work, besides silencing 
a warning seen only by git repo users?


>> Users of tarballs never see this, so this is only an issue for those on
>> oddball or ancient OS's, who are building release tarballs, or working
>> directly out the git repo.
>
> Well, if you say so...

Do you have knowledge to the contrary?

	Jeff