On Tue, Feb 3, 2015 at 12:17 PM, Tom H <[log in to unmask]> wrote:

> 1) RH doesn't license RHEL; it provides subscriptions to RHEL. The
> individual have licenses...

I think you meant "individual components have licenses", It's cool.

> 2) What might be the rationale for RH to release SRPMs (as SRPMs
> previously and as a git tree now) that are different from the SRPMs
> from which it builds RHEL?!

The most likely real reason would be accidental error. `Some SuSE 9
SRPM's for example, sometimes included different components form the
source tree in the SRPM depending on build options. Fedora and RHEL
have been very good about including *all* compnents, even if only used
for particular OS version or builds. I applaud them for consistency.

The other *potential* source of such a discrepancy would be a
manipulative weasel hiding hacks or concealing features incompatible
with patent or copyright law. I'm not saying this is *likely*, our
favorite upstream vendor has been really good about this, and I've met
enough of their employees in the Boston area to have some confidence
in them to not pull this sort of stunt. and if they got caught it
would be disastrous for public confidence and for their business

The potential of "trojan" binaries, even GPG signed trojan binaries,
are was one of the big reasons that when there have been any security
concerns about the upstream build servers thaey are so quickly taken
out of service, new build environments built, and the GPG keys
updated. Our friends at our favorite upstream vendor have been very
good about trying to deal with any question of the provenance of code.

> 3) The RPMs that are distributed by SL and CentOS are sometimes
> different from the RPMs that are distributed by RH because, for
> example, RH might use brpackage-x.y-1.el7 to satisfy
> package-i.j-k.el7's BuildRequires but might only release
> brpackage-x.y-2.el7. So SL and CentOS have to use the latter to build
> package-i.j-k.el7's.

Yeah, managing the relevant mock or koji resources can get a bit
tricky. There are also a few SRPM's in Red Hat's public repositories
up until now that have lacked necessary build components in any public
repository I've been able to find.  I particularly noticed the issue
when trying to compile Java based tools from the top level of
http://ftp.redhat.com/pub/redhat/ That's the sort of thing that makes
me throw up my hands and kick Java based applications out the door as
unsupportable.

But I'm also pretty picky.