On Tue, Feb 3, 2015 at 12:17 PM, Tom H <[email protected]> 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.
