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