Using git for patch management in Fedora

[Richard W.M. Jones]

On Thu, Nov 21, 2013 at 11:41:34AM +0100, Karel Zak wrote:
> On Thu, Nov 21, 2013 at 09:29:35AM +0100, Miroslav Suchý wrote:
> > And if you call simply `tito build --rpm` with builder configured as
> > `tito.distributionbuilder.DistributionBuilder`. It will create pristine tar
> > ball from last upstream tag (and that tar have same timestamps as upstream
> > and therefore md5 will match).
> 
> It's pretty common that people don't maintain autotools generated
> stuff in git. It means that upstream release (tarball) is not only
> source code from git but it also contains unique files generated on
> maintainer's machine. It means that for spec file Source: we still
> need the original upstream tarball.

Correct.

Some other random points slightly related to this:

 - Patches wouldn't normally patch the generated configure script, so
   the git repo wouldn't need to store the generated code in order to
   be useful as a store of patches.  I have used this git system to
   manage patches which are then applied on top of the pristine
   upstream tarball and it has always worked fine.

 - If you did patch the configure script you could add the generated
   files to git.  Or use the exploded tree git to store the tarball.

 - In any case I don't want to force anyone to use this system.  It's
   just a way to consolidate the duplicated work that at least 5 teams
   are currently using to manage patches.  You can quite happily keep
   using your own way of managing patches if you don't like it.

 - configure.ac that depends on specific old versions of autoconf is,
   as a rule of thumb, broken.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org