[Fedora-packaging] Re: Modifying upstream tarballs
Axel Thimm
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20070606/95ac9b50/attachment.bin
More information about the packaging
mailing list