[Fedora-packaging] Re: Modifying upstream tarballs

[Axel Thimm]

On Wed, Jun 06, 2007 at 05:35:37PM +0200, Patrice Dumas wrote:
> On Wed, Jun 06, 2007 at 03:52:21PM +0200, Axel Thimm wrote:
> > > No, it means "avoid running the autotools as part of building and patch
> > > instead to achieve deterministic builds for Fedora".
> > 
> > But the patches (to configure/Makefile.in) are supposedly generated in
> > a way that a typical Fedora system cannot reproduce, otherwise why not
> > generate them on the fly?
> 
> Because these changes should also be reviewed.

A one-liner in configure.ac can generate tons of shell script code,
what you would be reviewing is functionality of the autotools, and in
fact by submitting the package this way, this is what you implicitely
do.

Reviewing the same set of patches that you *didn't* generate yourself,
but got as an external patch to configure is far less reliables and in
fact a must.

So you're far better off to use autotools than to trust or review Joe
Random's use of it, as this is what an external patch to generated
files is.

> In some cases the patcheset is too big and complicated such that it
> may become right to call the autotools, but for many changes a diff
> to be reviewed for autotool generated files is better.

If the diff is really just replacing foo with foo2 or similar then I
agree, but if it involves modifed output due to changes in the
autotools workflow, then by all means no.

> > <ignoring uncomfortable sighing/>flex and yacc are also code
> > generators, so now we forbid the use of generating code? And what's
> > that --enable-maintainer-mode again? I guess autotools really disagree
> > with your POV.
> 
> The fact that something exists doesn't mean that it should be abused. 

No, you trimmed the sentence I replied to. There was a claim that
maintainers are not supposed to use autotools while autotools has an
explicit mechanism for maintainers which is also called that way. I
didn't say that --enable-maintainers is supposed to be used.

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.

> Flex and yacc also shouldn't be used in fedora. And when they need to 
> be it may be better to give the resulting diff, in case it is
> reviewable.

I was talking about upstream usage of flex/yacc not in scriplets, of
course. Because the defaulting to being enebaled maintainer-mode is
upstream just the like.

> > There is absolutely no reason to forbid generating code whatsoever, on
> > the contrary, it's far beter to have small master source file changes
> > that can be reviewed and modified than to have patches to generated
> > files that one cannot really modify anymore. You lose part of the
> > openness in open source that way.
> 
> 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?

> > And again: If the derived source code changes are not reproducible
> > with Fedora tools, then the package is neither revieable, nor
> > maintainable in Fedora space at all.
> 
> Not necessarily, if the patch to the autotool generated files are clear
> enough.

I agree. In simple replacements this will work. The problem is when to
draw the line, as everyone will define "simple" differently.

> I don't think rerunning autotools should be avoided at all costs, but 
> I have seen many reviews where it is easier to review the changes by
> providing patches for the primary files and for the generated files,
> to understand what changed also in the generated files.

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?

You will end up that the reviewer needs to perform the same steps that
could had been automated in the specfile, and noone would have to look
at how the generated configure/Makefile.in looks like if he reviews
the chnaged to the master files and the build is conducted giving the
expected results.

You don't review changes to assembly code that wer induced by changes
to the C code either.
-- 
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/ebb3fc9a/attachment.bin