On 06/19/2014 09:16 AM, Nico Kadel-Garcia wrote:
Take a look at even a simple SPEC file, such as "ntp.spec" to see how much interpretation it's doing.
Oh, I'm well aware of that.
Relying on the upstream authors to always do the .spec files *last* with new builds is not necessarily fair, and precludes certain type of code merges.
While I have no knowledge of the actual workflow at Red Hat, I would think that the population into git.centos.org would happen as an automated part of the upstream build process, and that what is going in to git.centos.org is what rpmbuild is seeing as it builds the 'canonical' upstream package (or it's being generated by depackaging the built SRPM). This would just about have to be true in order for the git.centos.org source to be the actual upstream source. Anyone with a valid subscription should be able to verify this for themselves by comparing the git committed source bundle with the subscription access SRPM.
This allows excellent change tracking with git (which many many people have asked for from CentOS in the past) while still getting the upstream source. Of course, it is a bit of a leap of faith to trust Red Hat to do it this way; but, then again, unless you have (or had) a valid subscription you couldn't verify that the source RPMs going into ftp.redhat.com were the same as what subscribers were getting (in terms of package metadata, and even perhaps a different signing key.....etc). IMHO, if you don't trust Red Hat to put the correct source into git.centos.org then why trust their source at all? The git commit ID's will take care of detecting side-channel modifications after Red Hat's populating of the source. (Side note: Linus' choice of the way commit ID's were to work is absolutely brilliant. IMHO).
But I'm curious as to what kind of merge would work with a depackaged source RPM but not with the files available through git.centos.org.
