[Fedora-packaging] Re: Modifying upstream tarballs
Axel.Thimm at ATrpms.net
Wed Jun 6 20:58:33 UTC 2007
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20070606/95ac9b50/attachment.bin
More information about the packaging