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:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Fri, 13 Jun 2014 10:22:08 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (71 lines)
On 06/13/2014 12:11 AM, Nico Kadel-Garcia wrote:
> The core CentOS deverlopers have, in my personal experience, never 
> been willing to discuss or expose the details of their internal build 
> environment. 
Times, they are a-changin'.

> 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. 

They use mock, and they published their mock configs a really long time 
ago.  I was able to get some details for my C5 IA64 rebuild project last 
year, and the CentOS core devs were very helpful when I asked them 
nicely for the info.  I've let the IA64 stuff languish for a few months, 
though; I may wait on 5.11 to rebuild those updates.  Doing the rebuild 
myself was an eye-opener, as many comments made by CentOS core devs in 
the 6.0 timeframe are made very clear indeed when you find out just 
exactly what was required to get 5.6 out of the door.  Rebuilding 
manually with mock and getting the dependencies just right was not easy 
with 5.6, in my experience.

I don't recall exactly which packages that were affected by this, but 
there was a particular library uprev from 5.5 to 5.6 that happened to 
impact another package, which wouldn't build correctly with the new 
version of that library, and thus was built against the older version 
(but there was another package that wouldn't build correctly with the 
older version).  If there is enough interest I might be able to dig that 
information up, but finding the particular build order for the 5.6 
update set (not all of the packages for which were issued in-order as 
separate updates, again IIRC) took iterative time, most of which was 
spent waiting on the machine to do the builds.  And there really wasn't 
any way to parallelize what I saw with 5.6, but I reserve the right to 
be wrong, too.  Nor did I know what order would work until a build 
completed and passed tests, at which point it was done anyway.  It was a 
lot like solving a Rubik's Cube; I can give you some basic sequences and 
algorithms, but each solution is going to require a different order of 
sequences of moves and I won't know what that order is going to be until 
it's solved.

Although I had an epiphany of sorts afterwards, but I haven't spent the 
cycles to try that idea out on the 5.5->5.6 upgrade.  (Short version of 
the epiphany: rpm -qp --queryformat "%{BUILDTIME}\n" $source-package 
).   When the update is issued (or populated to the upstream ftp source 
directory) is totally meaningless and unimportant; build time though 
does give you at least a possibility of finding out the contents of the 
buildroots (barring unpublished packages being used by the builds, which 
is always a possibility, and might very well have occurred for the 5.6 
package set, and barring hand-built packages with ad-hoc mock configs) 
at a given time.
> 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. 
IIRC SL6 uses koji (see 
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1011&L=SCIENTIFIC-LINUX-DEVEL&P=R531&I=-3 
).

Now, for 7, much of the details of those conversations are found on the 
CentOS-devel mailing list right now, with patches being accepted from 
the community, and two CERN devs being accepted into the CentOS Core 
group (to do work on koji, again IIRC; but you can read the thread in 
the -devel list yourself).  The change to git.centos.org as being the 
place where RH is dropping source is a real game-changer, and may make a 
koji-driven rebuild much more friendly (koji can rebuild from source 
RPM, but it prefers to build out of a repository, not a directory full 
of src.rpm's).

These are certainly interesting times.

And, of course, Russ has all sorts of good stuff online for clefos. You 
should check it out.

ATOM RSS1 RSS2