On Wed, 2008-10-15 at 01:19 -0400, Braden McDaniel wrote:
On Tue, 2008-10-14 at 10:50 -0400, Tom "spot" Callaway wrote:
On Sun, 2008-10-12 at 01:16 -0400, Braden McDaniel wrote:
I would like to make some progress on this:
<http://fedoraproject.org/wiki/PackagingDrafts/AutoConf>
The goal, I think, is incorporation of something like this into Fedora's Packaging Guidelines. I'm told this is the place to come.
This is the right place... do you feel that Draft is ready for us to consider it for inclusion in the Packaging Guidelines as is?
After some discussion on fedora-devel, I'd say "not yet".
ACK.
While I do think it's appropriate to steer packagers toward patching configure and Makefile.in for trivial cases, I'm coming around to the notion that for more complex cases the prose should restrict itself to being informational.
Not ACK. Patching auto-tools sources and generated files is always preferred, because only this guarantees deterministic builds.
If I were to decide, I would ban all calls to the autotools inside of specs, unfortunately, many people do not want to accept this thought, and consider running the autotools inside of *specs to be superior.
It's not a secret, I consider this practice to be "naive maintainers outsmarting themselves" and these people to be exposing Fedora packages to risks.
Unfortunately, I am preaching at walls :)
But I continue to think that certain invocations of the tools should be practically forbidden. ("autoreconf -f", I'm looking at you.)
autoreconf is just a wrapper aiming at automating invocations of the tools underneath and at replacing the plethora of (often broken) "bootstrap.sh / autogen.sh etc." scripts.
So, if you intend to ban autoreconf, you should be consequent and ban all calls to the autotools.
If you are aiming at banning "autoreconf -f" (Note: -f), then you are right, "autoreconf -f" is harmful in many cases.
Ralf