[Gluster-Maintainers] [gluster-packaging] glusterfs-3.8rc1 has been released for testing

Kaleb S. KEITHLEY kkeithle at redhat.com
Mon May 23 12:04:08 UTC 2016

Hash: SHA256

On 05/23/2016 03:13 AM, Niels de Vos wrote:
> On Sun, May 22, 2016 at 09:29:36PM -0400, Kaleb Keithley wrote:
>> ----- Original Message -----
>>> From: "Niels de Vos" <ndevos at redhat.com> To: "Emmanuel Dreyfus"
>>> <manu at netbsd.org> Cc: maintainers at gluster.org, "Kaleb S.
>>> KEITHLEY" <kkeithle at redhat.com>, packaging at gluster.org Sent:
>>> Friday, May 20, 2016 5:34:48 PM Subject: Re:
>>> [gluster-packaging] [Gluster-Maintainers] glusterfs-3.8rc1 has
>>> been released for testing
>>> On Fri, May 20, 2016 at 09:11:01PM +0200, Emmanuel Dreyfus
>>> wrote:
>>>> Niels de Vos <ndevos at redhat.com> wrote:
>>>>> Patrick filed https://bugzilla.redhat.com/1223937 for this
>>>>> during the 3.7 timeframe. I'm tempted to add the need to
>>>>> run autoreconf in the release notes unless someone really
>>>>> wants the config.sub/guess files back (we'll need to update
>>>>> the tools on the buildserver, but I would consider that a
>>>>> good thing anyway).
>>>> Please do not add autotools as a build dependency : It just
>>>> works with an empty config.sub file,
>>> Oh, that's genius! We can add an empty shell script that has a
>>> comment with suggesting to run "autoreconf --force". Some
>>> packaging environments prefer that in any case (Debian, I
>>> think) and Fedora even replaces the files automatically with
>>> their own updated copies (%configure).
>> Either an empty one or an up to date one from the latest
>> version(s) of autoconf/automake.
>> I'm not sure I know which is the better choice. Do you?
> I would go for the most practical choice. An empty (except for
> some comments) config.{guess,sub} and a note in the INSTALL file
> about it. If we would update those files from a more current
> version, we have to track future updates as well. My preference
> goes to solutions where we do not bundle any copies (script or
> other files) from other projects.

My point is that it's not really clear — to me — that that's the best
(or most practical) choice. I'd like to hear from Patrick and Emmanuel.

autoconf and automake haven't changed a great deal in the last few
years — i.e. there haven't been many new versions. I obviously can't
predict the future, but judging from the past few years keeping the
packages up to date would be a very small burden.

Independent of whichever solution we decide on, I'm going to update
autoconf and automake to the latest on build.g.o. And if that turns
out to be bad for some reason, it's easy to roll back to the previous

- -- 

Version: GnuPG v2


More information about the maintainers mailing list