Please add autoconf and automake to the buildroot

Steve Dickson SteveD at redhat.com
Sat Sep 23 02:05:32 UTC 2006


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..

> 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...

> 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...

> 
> ad absurdum: because mono allows cross platform assemblies some mono
> packages ship from upstream with prebuilt assemblies.  If the mono
> compile tools are not present on the system, these prebuilt assemblies
> may be used to construct the package.  This can open a security hole if
> an upstream package includes assemblies that weren't actually generated
> from the source code.  Should we include the mono stack to cover this?
Sorry I'm not familiar mono...

> 
> 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. ;-)

steved.




More information about the Fedora-maintainers mailing list