Gentoo Archives: gentoo-project

From: "Anthony G. Basile" <blueness@g.o>
To: Gentoo project list <gentoo-project@l.g.o>
Subject: [gentoo-project] [RFC] New Project: RelEng GRS
Date: Wed, 08 Jul 2015 17:14:13
1 Hi everyone,
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].
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" means copy ""
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
27 scripts, effectivley reproducing a catalyst run, see [6].
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.
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.
47 Ref.
48 [1]
49 [2]
50 [3]
51 [4]
52 [5]
54 [6]
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