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? If you do so w/o autotools' aid, then you're a masochist. ;) 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 ... > > 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. > > > There should be both in the diff: a diff to the Makefile.am file, for > > > example, and also the change to the Makefile.in. That way you have both. > > > > And what does the latter buy us? A patch to a generated file is very > > difficult to comprehend and verify unless it is a really trivial patch > > to the master source. You will have to verify the patch to the > > generated file by having a recipe on how to create it, which autotools > > called with what options, so why not embed that recipe into the > > specfile's scriptlet and only worry about the master file changes? > > 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. > > Why? What made these reviews so problematic? And why can't the > > reviewer just look at what is changing in the generated files on his > > system? How can the reviewer trust the submitter that the latter used > > autotools properly and didn't manually fix some things in the > > generated patches? > > By reviewing the patches. Help, we're talking in circles, let's agree to disagree! :) > > You don't review changes to assembly code that wer induced by changes > > to the C code either. > > Of course, but assembly diff is much harder to read than autotool > generated files diff. It depends on the viewer I guess. > 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. A more comparable analogon: You wouldn't patch a LaTeX generated (uncompressed) pdf file if you would just like to fix a typo. Anyway let's agree on disagreeing, I really just wanted to add my 2¢ and now the meter is already at 2€. ;) -- Axel.Thimm at ATrpms.net
Attachment:
pgp2c38yDiXof.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
