[Top][All Lists]

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

Re: Future autoconf package compression

From: Marko Lindqvist
Subject: Re: Future autoconf package compression
Date: Sun, 9 Dec 2012 03:50:58 +0200

On 8 December 2012 23:01, Jim Meyering <address@hidden> wrote:
> Marko Lindqvist wrote:
>> On 2 March 2012 06:45, Eric Blake <address@hidden> wrote:
>>> The Autoconf team is considering releasing only .xz files for 2.69; if
>>> this would be a hardship for you, and you need the .gz or .bz2 release,
>>> please speak up now.
>>  I just encountered new argument for providing .gz of autoconf also in
>> the future.
>>  I were updating automake version used in OpenEmbedded, and though to
>> switch from tar.gz to tar.xz package while at it. That failed because
>> of circular dependency. In short: building xz decompressor requires
>> automake.
> Hi Marko,
> I have simulated building xz with a broken version of automake:
> (similar to when automake is not installed)
>     wget
>     tar xf xz-5.0.4.tar.xz
>     cd xz-5.0.4
>     mkdir x; printf '#!/bin/sh\nexit 1\n' > x/automake; chmod a+x x/automake
>     PATH=x:$PATH ./configure && make && make check
> All of those commands succeeded, so it is clear to me that building
> xz that way does not depend on automake.

 The fact that I were talking about OpenEmbedded build is significant.
OpenEmbedded adds the dependency. AFAIK every tool (autotools, xz,
OpenEmbedded) works correctly as designed, but there's conflict
between their designs.
 I have no power to make changes to any of the projects - I can only
suggest things, but overall I think it's OpenEmbedded where changes
should be made (and are easiest to make). But until we have right
thing(tm) fix in place, simply providing also gzip compressed tarballs
of autotools would workaround the problem.

 - ML

reply via email to

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