[Fedora-packaging] Re: Modifying upstream tarballs

[Patrice Dumas]

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