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.
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?
~spot
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".
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. But I continue to think that certain invocations of the tools should be practically forbidden. ("autoreconf -f", I'm looking at you.)
I'll ping back here when I think it's ready.
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
On Wed, 2008-10-15 at 07:48 +0200, Ralf Corsepius wrote:
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.
"and"? If you're patching both the sources *and* the generated files, couldn't you wind up in a situation where the source is newer than the generated files (i.e., the source gets patched after the generated file)? If that happens, "make" calls the tools to regenerated stuff and you've just outsmarted yourself. This subtlety is avoidable with multiple different patches (applied in the correct order), of course; but for the purpose of a guideline, I'm inclined not to recommend patching both.
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.
I agree, but I'm inclined to take a pragmatic approach where a package maintainer might need to do extensive patching to the build scripts. I think it's an exceptional case, but I don't want to make that guy's life hell.
OTOH, I would certainly want the guideline to make clear that the autotools should not be run just for the hell of it (i.e., because the package maintainer wants to make sure the "latest stuff" gets used).
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 :)
We're on the same page ideologically. But I want to find something that will be palatable to most packagers while addressing the most glaring potential for breakage.
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.
My motivation for banning autoreconf would be that it is a shotgun. I don't know if it can be relied upon to check timestamps and regenerate only what needs regenerating. I wouldn't want someone who needs to patch Makefile.[am/in] to wind up regenerating configure--that's silly.
If it *can* be relied upon to respect timestamps, then I have no more quarrel with its use than I have with invoking any of the autotools directly. (Which is not to say that I have no quarrel with it.)
If you are aiming at banning "autoreconf -f" (Note: -f), then you are right, "autoreconf -f" is harmful in many cases.
I'd say every case.
On Wed, 2008-10-15 at 02:57 -0400, Braden McDaniel wrote:
On Wed, 2008-10-15 at 07:48 +0200, Ralf Corsepius wrote:
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.
"and"? If you're patching both the sources *and* the generated files, couldn't you wind up in a situation where the source is newer than the generated files (i.e., the source gets patched after the generated file)?
Yes, it would require preserving timestamps and/or touching files.
Preserving timestamps isn't easily doable with rpm (c.f. option -T in man patch), but touching often is very simple. Depending on the complexity of a patch and the complexity of a package, normally reduces to very few touch'es (working principle: set the time stamps of modified files to that of an unmodified file at the root of auto*tools dependency)
e.g. often a touch -r aclocal.m4 configure.* or similar after applying a patch works.
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.
My motivation for banning autoreconf would be that it is a shotgun.
Agreed.
I don't know if it can be relied upon to check timestamps and regenerate only what needs regenerating.
AFAICT, older autoreconf's had been problematic, but newer ones seem to work quite well with packages having been developed with modern autotools - At least, I haven't see a breakage for while a while.
I wouldn't want someone who needs to patch Makefile.[am/in] to wind up regenerating configure--that's silly.
It's not that silly, because newer automake/aclocal's require newer autoconf's.
The effects only show on rare occasions, nevertheless they occasionally show. However, more often you encounter cases, where regenerating Makefile.am's with new automakes breaks Makefile.ins, which had been developed with old automakes.
If it *can* be relied upon to respect timestamps, then I have no more quarrel with its use than I have with invoking any of the autotools directly. (Which is not to say that I have no quarrel with it.)
If you are aiming at banning "autoreconf -f" (Note: -f), then you are right, "autoreconf -f" is harmful in many cases.
I'd say every case.
:)
Ralf
On Wed, 2008-10-15 at 09:39 +0200, Ralf Corsepius wrote:
On Wed, 2008-10-15 at 02:57 -0400, Braden McDaniel wrote:
[snip]
I wouldn't want someone who needs to patch Makefile.[am/in] to wind up regenerating configure--that's silly.
It's not that silly, because newer automake/aclocal's require newer autoconf's.
Good point; but automake isn't terribly aggressive about this. For instance, I don't think automake 1.10 depends on any autoconf features/fixes past 2.59. In general, I think one is better off using the packaged configure until it breaks.
Braden McDaniel braden@endoframe.com writes:
Not ACK. Patching auto-tools sources and generated files is always preferred, because only this guarantees deterministic builds.
"and"? If you're patching both the sources *and* the generated files, couldn't you wind up in a situation where the source is newer than the generated files (i.e., the source gets patched after the generated file)?
Use 'touch --reference' and submit an patch to upstream which adds 'AM_MAINTAINER_MODE' to configure.ac.
Enrico
On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote:
Braden McDaniel braden@endoframe.com writes:
Not ACK. Patching auto-tools sources and generated files is always preferred, because only this guarantees deterministic builds.
"and"? If you're patching both the sources *and* the generated files, couldn't you wind up in a situation where the source is newer than the generated files (i.e., the source gets patched after the generated file)?
Use 'touch --reference' and submit an patch to upstream which adds 'AM_MAINTAINER_MODE' to configure.ac.
Many maintainers have made a conscious choice not to use that macro. I know I have.
On Wed October 15 2008, Braden McDaniel wrote:
On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote:
Use 'touch --reference' and submit an patch to upstream which adds 'AM_MAINTAINER_MODE' to configure.ac.
Many maintainers have made a conscious choice not to use that macro. I know I have.
Why?
Regards, Till
On Wed, 2008-10-15 at 10:53 +0200, Till Maas wrote:
On Wed October 15 2008, Braden McDaniel wrote:
On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote:
Use 'touch --reference' and submit an patch to upstream which adds 'AM_MAINTAINER_MODE' to configure.ac.
Many maintainers have made a conscious choice not to use that macro. I know I have.
Why?
I can't speak for Braden, but AM_MAINTAINER_MODE is _VERY_ controversial. Some people like it, others hate it.
Read "info Automake" for more details.
In a nutshell: AM_MAINTAINER_MODE suppresses the deps we are discussing here.
This allows people to get away with packages containing broken timestamps, which introduces risks to upstreams if not handled with care and is unhandy for upstream usage.
FWIW: I am upstream maintainer of a package, which uses AM_MAINTAINER_MODE. The most frequently answered question related to building issues is: "Did you pass --enable-maintainer-mode?"
Openly said, I regret ever having introduce it to this package's configuration.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
AM_MAINTAINER_MODE suppresses the deps we are discussing here.
This allows people to get away with packages containing broken timestamps, which introduces risks to upstreams if not handled with care and is unhandy for upstream usage.
When you are upstream, you have probably mechanism/scripts to call configure with special parameters (e.g. adding '-g3' to CFLAGS, setting a writable '--prefix', setting another CC). Putting an '--enable-maintainer-mode' there does not harm.
I am upstream maintainer of a package, which uses AM_MAINTAINER_MODE. The most frequently answered question related to building issues is: "Did you pass --enable-maintainer-mode?"
Reducing stability (-> occasional autotool invocations in uncontrolled environments) and removing features (-> ability to patch configure) just to avoid some support requests is a bad deal.
Enrico
On Wed, 2008-10-15 at 11:47 +0200, Enrico Scholz wrote:
Ralf Corsepius rc040203@freenet.de writes:
AM_MAINTAINER_MODE suppresses the deps we are discussing here.
This allows people to get away with packages containing broken timestamps, which introduces risks to upstreams if not handled with care and is unhandy for upstream usage.
When you are upstream, you have probably mechanism/scripts to call configure with special parameters (e.g. adding '-g3' to CFLAGS, setting a writable '--prefix', setting another CC). Putting an '--enable-maintainer-mode' there does not harm.
My problem is a bit different (cf. below).
I am upstream maintainer of a package, which uses AM_MAINTAINER_MODE. The most frequently answered question related to building issues is: "Did you pass --enable-maintainer-mode?"
Reducing stability (-> occasional autotool invocations in uncontrolled environments) and removing features (-> ability to patch configure) just to avoid some support requests is a bad deal.
People (developers) are working on CVS check outs and wonder why the Makefile don't do what they expect rsp. why their autotool-generated files don't get updated, when rebuilding their works.
Cause: They forgot --enable-maintainer-mode.
Ralf
On Wed October 15 2008, Ralf Corsepius wrote:
People (developers) are working on CVS check outs and wonder why the Makefile don't do what they expect rsp. why their autotool-generated files don't get updated, when rebuilding their works.
Cause: They forgot --enable-maintainer-mode.
I guess it would help to add "--enable-maintainer-mode" to the autogen.sh script or create such a script that should be run by maintainers, instead of making everyone type this option manually.
Regards, Till
On Wed, 2008-10-15 at 10:53 +0200, Till Maas wrote:
On Wed October 15 2008, Braden McDaniel wrote:
On Wed, 2008-10-15 at 09:52 +0200, Enrico Scholz wrote:
Use 'touch --reference' and submit an patch to upstream which adds 'AM_MAINTAINER_MODE' to configure.ac.
Many maintainers have made a conscious choice not to use that macro. I know I have.
Why?
* Many users expect the dependency checking it turns off by default to be on by default. * I think it is entirely appropriate to expect those who play with the timestamps of files in a distribution to take care when doing so.
And what Ralf said.
And as Ralf noted, this macro is controversial enough to have that controversy noted in its documentation in the Automake manual. Rehashing that controversy here isn't going to change anything.
On Wed, Oct 15, 2008 at 01:19:15AM -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".
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. But I continue to think that certain invocations
I think that it would be very nice if you could summary the whole conversation in http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks with a (controversial) in the title.
I personnally think that this kind of complicate recommendation should not be in the guideline in any case, the guidelines are already too big, but it should definitively be somewhere such that one has just to point to the text when doing reviews.
-- Pat
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.
Note that I will vote against this draft as written but I'm only one person on the FPC :-)
I outlined in the other thread what kind of draft I would vote for.
-Toshio
packaging@lists.fedoraproject.org
-
Braden McDaniel -
Enrico Scholz -
Patrice Dumas -
Ralf Corsepius -
Till Maas -
Tom Callaway -
Toshio Kuratomi