Subject: | |
From: | |
Reply To: | |
Date: | Thu, 19 Jun 2014 09:47:11 -0400 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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.
|
|
|