its slightly more complicated than that because all of the copyrighted
logos, themes need to be stripped out. In addition there are a few
pieces of software needed for compile dependencies which aren't
included in the standard RH base due to the fact that they are sold as
addons.

That said yes it is possible in fact most of it can be done with a
$100 a year developers support license.
The overwhelming reason I heard when this was being debated is that
the RHN API's are to slow to easily mirror which is somewhat true. the
spacewalk APIs are complicated and slow for this kind of mirroring.
that said the new subscription manager is uses standard yum repos with
PKI auth (they issue you an ssl certificate) so I never understood the
argument to go to git completely my self.

I suspect there may be other aspect to this decision we are not aware
of because I know CERN and Fermilab  had conversations with Red Hat
about this but due to NDA's may not be able to tell us every thing
they learned which lead them to this decision.

On Wed, Sep 3, 2014 at 8:38 AM, Andreas Mock <[log in to unmask]> wrote:
> Hi Nico,
>
> thank you for your both answers.
>
> I'm really not happy to hear this summary and I really don't understand it.
> (But I have an idea why it was done this way by RH)
>
> Is there not much more skepticism out there for the validity/integrity of the sources?
>
> Just because I'm curious: Would it be legal to buy one RH subscription to
> get the SRPM to build a clone from that? I'm asking because an organisation
> like Femilabs or CERN should have the money to buy one subscription to
> have a sane base for a clone. And I've chosen SL because I hoped to have
> a distribution with stability in mind. So, up to now every update and upgrade
> worked like a charm. Big thumb up for all who did this work.
>
> Best regards
> Andreas Mock
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Nico Kadel-Garcia [mailto:[log in to unmask]]
>> Gesendet: Mittwoch, 3. September 2014 13:33
>> An: Andreas Mock
>> Cc: Patrick J. LoPresti; Pat Riehecky; SCIENTIFIC-LINUX-
>> [log in to unmask]
>> Betreff: Re: AW: [SCIENTIFIC-LINUX-USERS] Questions about SL 7.0
>>
>> On Wed, Sep 3, 2014 at 4:33 AM, Andreas Mock
>> <[log in to unmask]> wrote:
>> > Hi Pat, hi Patrick,
>> >
>> > thanks for your answers and comments.
>> >
>> > How would someone like me get a SRPM for a binary package found or
>> > installed on a SL 7.0 system?
>> >
>> > I really don't understand in the moment how it is verified that
>> > sources are from RH and unaltered by someone in between.
>> >
>> > Best regards
>> > Andreas Mock
>>
>> Our favorite upstream vendor signs the SRPM's and RPM's with GPG
>> signatures, whicih can be verified from their public websites and their
>> installation media. So do CentOS and Scientifici Linux.
>>
>> Now, if I could just convince our new upstream software friends over at
>> git.centos.org to use GPG signatures for git tags, I'd be much happier about
>> the provenance of software in that new public repository. I'd be even
>> happier if the person from Red Hat who uploads the original source code
>> from Red Hat would GPG sign a tag for *just that code* with a Red Hat key,
>> and our CentOS maintainers (some of whom are now Red Hat employees!)
>> could GPG sign tags for CentOS modified software. But I'd be thrilled to
>> pieces if they'd even affix a CentOS tg to the Red HAt uploaded content, just
>> for the provenance concerns I've already raised.
>>
>> Sadly, my concerns about provenance have been ignored, and now the
>> existing Scientific Linux development from git.centos.org is being held up as
>> proof that git tags are not desirable and my concerns ill founded. It's quite
>> galling: the current semi-manual re-assembly of local branches, based on "git
>> log" entries, is winding up lauded as sufficient and superior because, frankly,
>> it's the only thing that's currently supported.
>>
>> It's really quite galling. I've gotten quite put out with every sys-admin in the
>> world thinking they can re-invent the wheel, and coming up with their own
>> mismatched wheels, to replace what are well designed software features
>> like git 'tags'.