On Wed, Jun 06, 2007 at 10:58:33PM +0200, Axel Thimm wrote: > On Wed, Jun 06, 2007 at 10:26:04PM +0200, Patrice Dumas wrote: > > But I personally find that not that hard to review the changes in > > configure, especially when one get used to. > > Look at the size difference of configure.ac and configure. For example > xlibs/Render: > > 81252 configure > 1513 configure.ac > > So one each configure.ac line you have 53 configure lines. You're used > to review that these 53 lines really reflect the cahncges in the > master? W/o running autotools youirself to verify this? I try to do both. > If you do so w/o autotools' aid, then you're a masochist. ;) Maybe... I don't say that I read all the details, though. > If you use autotools, then why not use them in the sepcfile and have a > manual step to perform? Manual steps either slow down the process or > are easily skipped and not done at all ... Because the generated files changes should be reviewed, and by freezing that there won't be new changes with new autotools. > > > And note, that AM_MAINTAINER_MODE defaults to --enable-maintainers if > > > not used!!! Which means that 99% of all projects already "abuse" this > > > if they want to or not. > > > > I disagree. I don't think this feature is for released packages, but it > > is to be used between releases only. Of course I don't want to force > > anybody ;-). > > Please read the docs. Autotools and even the author of the > AM_MAINTAINER_MODE recommend to *not* turn off maintainer rules for > very good reasons. These reasons apply here as well. This has nothing > to do with released packages or released software whatsoever. The reason is "change to sources files can have no effect on generated files and this can be very confusing when unnoticed. " So, yes I am all for having AM_MAINTAINER_MODE set, but it should be used only to notice that something was modified such that the maintainer understand what is happening and fix the timestamps and verify what changed. > > To verify the patch it is better to have a recipe to recreate it, sure, > > (it could be in comments in the spec file for example) but to review it, > > the diff of the generated file may be enough. > > If you need a recipe, then automate it. But by doing that you also generate a new output file. > > But maybe there was also some humor, here... > > Sure, but a lot of truth as well. The general rule is that when there > are build chains, only touch the highest master, not intermediate > files. Indeed in general it is better, but here it is not exactly the same because the generated files have a double role. > A more comparable analogon: You wouldn't patch a LaTeX generated > (uncompressed) pdf file if you would just like to fix a typo. Sure, but in the case of the autotools generated files those files may have non-trivial consequences. > Anyway let's agree on disagreeing, I really just wanted to add my 2¢ > and now the meter is already at 2€. ;) No problem, I am not sure that we disagree that much, we should look at particular reviews to know for sure. -- Pat -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
