SCIENTIFIC-LINUX-USERS Archives

June 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Fri, 13 Jun 2014 00:11:58 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (53 lines)
On Thu, Jun 12, 2014 at 6:28 PM, Yasha Karant <[log in to unmask]> wrote:
> I have the following, possibly silly, question to post.  As I understand it,
> access to the git repositories meets TUV linux/GPL requirements for release
> of the source.  Nonetheless, the realities are that it is easier to build
> from the actual SRPMs that TUV uses.  These are not to be released by TUV.

This is where you're following a flawed path, I'm afraid. From
experience with Fedora, and personal experience building RPM's from
source, if you generate "tags" in git, it's as trivial to build from
the git tags as it is from SRPM's. If the tags are signed, you have
similar checksums in the total source bundle as you would with an
SRPM, and you can have similar confidence in the provenance of the
source code you're working from.

git repositories *can* be as easy to use as SRPM's, *if* they are
tagged, and *if* there is a way to obtain an index of the relevant
tags of a particular point release. So the risk isn't in using git:
it's in the lack, so far, of relevant tags to distinguish RHEL source
code from whatever CentOS may choose to modify, and the potential for
unknown changes between the RHEL internal git repositories and
whatever CentOS may choose to integrate and publish.

> Presumably, CentOS, as what amounts to an owned subsidiary of Red Hat, uses
> SRPMs and the like to build CentOS internally -- or has a very extensive
> tool set for the git repositories.  My guess is that both TUV and CentOS

Similar to what RHEL uses and Fedora uses, Take a look at the "mock"
software and the relevant koji tools to see how a small set of RPM's,
built on an older OS, can be bootstrapped into a full set of RPM's for
a production environment. It's like building gcc: First you have to
build or cross-compile a toolkit capable of building your component
building toolchain in the environment you want, then build the new
toolkit with the new toolkit to make sure things are consistent: then
you test it thoroughly, if you're wise, and only *then* do you use it
to build other components.

> construct SRPMs from the git repositories to build the respective
> distributions.  Hence, there most likely are (must be) tools/utilities that
> create from the git repositories a compatible coherent set of SRPMs.  Can
> the SL groups either get those tools from CentOS or can these tools be
> recreated?  For a system as complex as EL, any modern version of a build
> environment uses automation -- tools.

The core CentOS deverlopers have, in my personal experience, never
been willing to discuss or expose the details of their internal build
environment. I'm afraid I tried to find out details a few times, such
as whether they use 'mach' or 'mock', and did not get very far. I've
not tried to dig into Scientific Linux's build environment.

That's actually a good question, though a separate one. Are the
details of the the Scinetific Linux build system publicly available?
I've not personally gone digging.

ATOM RSS1 RSS2