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 |