On 06/19/2014 02:05 PM, Yasha Karant wrote:
> The bottom line to this issue seems to have two parts:
Pretty good distillation. Comments in-line.
>
> 1. Is it feasible with the same personnel resources and hardware
> computational resources to acquire and build current, maintained SL 7
> from the current, maintained RHEL 7 production source?
If you can accept that the incoming commits to git.centos.org, per Red
Hat's statement in bugzilla.r.c, are the 'RHEL 7 production sources,'
then yes, it is possible, and the work is progressing. If you're
talking about the source RPMs that are currently only available to
subscribers, then, no, it's not possible at this time.
> Note this query also means to keep SL 7 production (sl7x) as current
> as RHEL 7 production, except for the (hopefully short) delay from the
> time RH releases production source updates/enhancements to the time SL
> can release the same as installable RPMs.
Looking at the many repositories in git.centos.org, it appears that they
are being updated; as I don't have a production RHEL7 system with which
to compare, I have insufficient data with which to comment on how timely
those commits are or are not. Time will tell.
>
> 2. Is it verifiable, not just on a claim of trust, that the
> production source from which SL 7 (and 8 and ... ) is built is the
> same production source used for the commercial for-profit RH supported
> RHEL 7 RPM distribution?
If you have an RHEL subscription you can verify this for yourself by
comparing the source RPMs from the subscription to the sources committed
to git.centos.org.
> This latter statement is the basis for the validity of open source --
> the source can be inspected (audited, if necessary), and the two
> sources compared. If this cannot be verified, then we do not know how
> CentOS, SL, etc., differ from RHEL (other than trivial logos and the
> like), and what software defects exist that are not present in RHEL.
>
This is the sticky wicket, isn't it? The fact of the matter is that
RHEL source only has to be directly distributed to subscribers who have
been distributed a copy of the binaries. We've trusted Red Hat to
populate ftp.redhat.com with the correct sources (without independent
verification against subscription source RPMs) in the past; this is a
change of delivery method, for sure, and will require some adjustments
on our part. However, I would like to point out something, using the
output of a whois:
[lowen@dhcp-pool107 ~]$ whois centos.org
[Querying whois.publicinterestregistry.net]
[whois.publicinterestregistry.net]
Domain Name:CENTOS.ORG
Domain ID: D103409469-LROR
Creation Date: 2003-12-04T12:28:30Z
Updated Date: 2014-06-18T07:43:39Z
Registry Expiry Date: 2015-12-04T12:28:30Z
Sponsoring Registrar:Nom-iq Ltd. dba COM LAUDE (R1772-LROR)
Sponsoring Registrar IANA ID: 470
WHOIS Server:
Referral URL:
Domain Status: clientDeleteProhibited
Domain Status: clientUpdateProhibited
Domain Status: serverTransferProhibited
Domain Status: transferPeriod
Registrant ID:COMLDE-011441
Registrant Name:Red Hat, Inc.
Registrant Organization:Red Hat, Inc.
Registrant Street: 100 East Davie Street
Registrant City:Raleigh
Registrant State/Province:NC
Registrant Postal Code:27601
Registrant Country:US
Registrant Phone:+1.9197543700
Registrant Phone Ext:
Registrant Fax: +1.9197543704
Registrant Fax Ext:
Registrant Email:[log in to unmask]
.....
If anyone was uncomfortable about a centos.org domain machine holding
Red Hat sources, well, Red Hat is the registrant of the centos.org domain.
Hope that helps.
|