[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