| 1 |
Hi everyone, |
| 2 |
|
| 3 |
I'd like to announce a new Release Engineering subproject that I'm |
| 4 |
working on called the Gentoo Reference System (GRS) Suite [1]. It is a |
| 5 |
set of utilities written in python [2] that allows one to build and |
| 6 |
maintain well defined identical Gentoo systems from a set of |
| 7 |
configuration files and scripts housed on a branch of a central git |
| 8 |
repository [3]. GRS has overlaps with catalyst and can be used to build |
| 9 |
stage tarballs, but it is not meant to be a catalyst replacement. |
| 10 |
Rather it grew out of the need to generalize the build mechanism for my |
| 11 |
uclibc desktop system [4]. |
| 12 |
|
| 13 |
Basically GRS works as follows: On a server you run a utility called |
| 14 |
grsrun which clones/pulls a remote git repo and checks out some branch |
| 15 |
that contains all the specs to build a particular GRS system. An |
| 16 |
example of such a branch specifiying a GRS system can be seen at [5]. A |
| 17 |
main script called "build" contains the steps grsrun is to take, eg |
| 18 |
"populate" means copy in a set of files from the "core" directory into |
| 19 |
the chroot of the new system, or "runscript foo.py" means copy "foo.py" |
| 20 |
from the "scripts" directory into the chroot and run it. Since the |
| 21 |
files copied in or scripts run are quite general, pretty much any system |
| 22 |
can be created --- just think of the steps you would take in building a |
| 23 |
system from a stage3, code them up as bash or python script and GRS will |
| 24 |
replicate them. Thus you can copy in preconfigured themes and home |
| 25 |
directories, etc into your system and produce a well polished release. |
| 26 |
This generality also allows grsrun to do catalyst stageX-chroot.sh |
| 27 |
scripts, effectivley reproducing a catalyst run, see [6]. |
| 28 |
|
| 29 |
grsrun operates in two modes: release mode is intended to go through all |
| 30 |
the steps in the build script and generate some release tarball or iso |
| 31 |
image. In contrast, update mode only executes certain steps in the |
| 32 |
build script and is intended for building updates since the last release. |
| 33 |
|
| 34 |
GRS also provides a client tool called grsup to keep a GRS system up to |
| 35 |
date. grsup is a wrapper to emerge which not only updates the system, |
| 36 |
but also maintains all the configurations under /etc/portage in line |
| 37 |
with the GRS specs --- the idea is that all systems conforming to a |
| 38 |
particular GRS specs are "identical" in some sense. This means that as |
| 39 |
long as a user is following the GRS specs, he doens't have any choice of |
| 40 |
USE flags, but that doesn't prevent him from deviating from the GRS |
| 41 |
specs and treating his system from that point on as any other Gentoo |
| 42 |
system. Indeed, provided he hasn't deviated too far, he can even return |
| 43 |
to the GRS specs. The point of a GRS system is to be exactly that, a |
| 44 |
*reference* system which is well defined and identically reproduceable. |
| 45 |
|
| 46 |
|
| 47 |
Ref. |
| 48 |
[1] https://wiki.gentoo.org/wiki/Project:RelEng_GRS |
| 49 |
[2] https://gitweb.gentoo.org/proj/grss.git/ |
| 50 |
[3] https://gitweb.gentoo.org/proj/grs.git/ |
| 51 |
[4] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc/Lilblue |
| 52 |
[5] |
| 53 |
https://gitweb.gentoo.org/proj/grs.git/tree/?h=desktop-amd64-uclibc-hardened |
| 54 |
[6] https://gitweb.gentoo.org/proj/grs.git/tree/?h=stages-amd64-hardened |
| 55 |
|
| 56 |
-- |
| 57 |
Anthony G. Basile, Ph.D. |
| 58 |
Gentoo Linux Developer [Hardened] |
| 59 |
E-Mail : blueness@g.o |
| 60 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 61 |
GnuPG ID : F52D4BBA |
Archives