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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
