SCIENTIFIC-LINUX-DEVEL Archives

January 2012

SCIENTIFIC-LINUX-DEVEL@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:
Karanbir Singh <[log in to unmask]>
Reply To:
Karanbir Singh <[log in to unmask]>
Date:
Mon, 23 Jan 2012 00:13:24 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (53 lines)
Hi Guys,

I was pointed to this thread by someone, am glad they did. I'm keen on
helping and can push some resources this way.

On 01/21/2012 11:39 PM, Douglas McClendon wrote:
> First, where I alluded to 'choice b' I meant 'decision b' as a couple
> sentences later I define an actual choice b.  Second, the bit about
...
> build all of the 6.0 packages.  So rebootstrapping the minbuildroot as I
> described, while sounding good in some ideal theory way, probably won't
> work without significant alternate workarounds to the issues that
> currently require F12/F13/RHEL6Beta for various package build deps. Thus
...
> likely you'd modify them such that you don't need all those
> F12/F13/RHEL6beta initial bootstrap binaries (thus reducing your input
> complexity/threat surface).

The fact that multiple bootstraps are needed are by far the easiest of
the issues to resolve. And actually, that's not true. Multiple Distro's
were not needed to achieve the desired result, but was the easier option.

The larger and more difficult issue to solve is the in-time-root-traversal.

> Anyway...  again, just trying to give people a feel for the real scope
> of the issues at hand.  My own engineering strategy is to get _any_
> deterministic process laid down and producing remotely-reasonable output
> first, then to easily go and tweak the fully automated/coded build

Firstly, what/where is your assert() going to take place ?

Secondly, what/where is your assert() going to take place without
inheritying legal liability ( both internally and downstream to userbase )

> process towards a more optimal/puritanical path iteratively after that.
>  Ideally such that by the time EL7 comes out, the turnaround time for
> updating the deterministic buildscripts is really short, because all
> these issues have been tackled and solved in code for EL6 already.

EL7 is again going to be a different ballgame, however we are taking a
few steps in the CentOS side of things to try and get a few bits further
automated.

( I need to catchup with some of the links mentioned in the thread so
far, lots of things that I've never come across before + time is in
short supply, but will try to keep up )

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219    | Yahoo IM: z00dax      | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc

ATOM RSS1 RSS2