On Thu, Jun 19, 2014 at 9:47 AM, Lamar Owen <[log in to unmask]> wrote:
> 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.

There are a stack of ways to do this, some less reliable than others.
They're not clearly making "git clones" of the upstream RHEL git
repository. there is some kind of "import" of the files happening. If
they're simply unpacking the SRPM's and importing those, cool. But
import/export procedures with git are prone to fascinating
discrepancies, some from user error, It creates fascinating risks, and
without a carefully comparison toolkit that compares either RHEL
SRPM's to git.centos.org's unstated and thus unpredictable layout, or
someone with git access to both running "git diff" between the repos,
it's a small but very real risk of fascinating discrepancies.

I'm afraid that the only way to get a valid, reliable, and *signed*
set of source code is going to be to buy subscriptions.

> 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.

See above. The careful tracking of upstream is happening out of view.

> 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

But at least they had a GPG signature, from Red Hat, saying "we
published this". That signature is still present when I hand you a
copy of the SRPM or put it in a local mirror or get it from Scientific
Linux's vendor mirror. git.centos.org has no GPG tags, not even on
their initial imports. I'm fairly shocked: it puts all git clones of
git.centos.org material at risk of unauthorized modification and
pollution of the source code for people trying to build from them.

> 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.

There's no way, as things stand, to tell which is the "vendor" version
nor which is the "centos build" version of the code in git.centos.org.
There's not even a tag or branch to indicate it, just a "master" on
which changes are accumulating. And it's already gotten polluted. Is
the new "centos-git-common" repository part of the official RHEL
releases? I think not, but it's in the same environment that formerly
contained purely RHEL code. How can we tell future such packages
apart?

SL did this very well, with the separate "sl6" and "vendors"
directories for SRPM's from Scientific Linux, and tools from upstream
vendors like Red Hat. A similar separation would have been very
welcome at www.centos.org, but somehow, I don't see them resetting the
URL's in all their working git clones.