Please add autoconf and automake to the buildroot

[Jima]

On Fri, 22 Sep 2006, Steve Dickson wrote:
> Toshio Kuratomi wrote:
>> You haven't addressed Paul's point that it's easier for us (we're
>> supposed to be knowledgable packagers, right?) to detect these errors
>> than for people downloading the SRPM and rebuilding in their local
>> environment to do so. 
> In this particular case it wouldn't be ways for either them or us
> because the errors are undetectable... but I truly doubt their
> locally build rpm will end up on thousands of desktop via yum
> marrying corrupting machines as they go. The point being we should put
> in safeguards in that will stop us from sending out corrupted rpms
> and by adding those packages we are doing just that... imho..

  If the errors are undetectable, then I consider it all the more reason 
for you to add BRs for autoconf/automake.  As stated previously, your case 
isn't really any different than any other missing BuildReqs that cause 
weird behavior in the resultant packages.

>From an earlier email:
> Jesse Keating wrote:
> > I don't accept your claim that these are the most common used packages 
> > to build our rpms.
>
> These tools have been around since the early days of UNIX and have been 
> used every since... so whether you accept that or not is.... well... 
> indifferent...

  Unless you want to s/UNIX/Linux/, Toshio seemed to discount this claim. 
But, regardless of how old they are, age does not equal importance.  I 
have a relatively meager package load (11), but only one of my packages 
uses autoconf.  I asked Spot, as he has more packages (101); only three 
use autoconf or automake.  A small sampling, for sure, but I can't help 
but wonder if it's at least vaguely representative.

>> You also haven't addressed Jesse's points that
>> this applies to many other packages besides autoconf and automake (what
>> makes this case exceptional?) 
> They stop undetectable RPM corruption...

  That's generally the point of correctly defining your BuildReqs.

>> or his point that part of being a packager
>> is to look over the build logs to be sure your package not only built
>> but built the way you expected it to.
> And me tell why its not a broken build system when we have to scour over
> successful build logs looking for data corrupters...

  Sounds more like broken packages, personally.

>> If you think that autoconf and automake should require an extra level of
>> error checking, you might also consider writing a test for rpmlint that
>> checks patches for changes to Makefile.am, configure.ac, etc, and if it
>> finds some, makes sure that the spec file calls autoconf, automake, or
>> autoreconf.  This can benefit people who are not using our particular
>> buildsystem as well.
> Or just add two very small, highly used packages to the buildroot. ;-)

  Would you mind ennumerating "highly used?"

      Jima