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