Skip to content
Browse files

Merge pull request #13 from zentoo/master

refactoring, livecd target & documentation
  • Loading branch information...
2 parents 3a684ed + 0919654 commit 85b93101054acef5a006e458357f20355917e214 @angryvincent angryvincent committed Mar 12, 2012
Showing with 650 additions and 143 deletions.
  1. +282 −0 README.rst
  2. +12 −1 etc/builds/funtoo-current/build.conf
  3. +12 −1 etc/builds/funtoo-experimental/build.conf
  4. +12 −1 etc/builds/funtoo-stable/build.conf
  5. +11 −1 etc/builds/gentoo-stable/build.conf
  6. +6 −8 etc/fslayouts/funtoo/layout.conf
  7. +2 −1 etc/metro.conf
  8. +1 −0 modules/targets.py
  9. +6 −4 targets/gentoo/lxc.spec
  10. +6 −4 targets/gentoo/openvz.spec
  11. +51 −0 targets/gentoo/source/README.rst
  12. +0 −11 targets/gentoo/source/seed.spec
  13. +2 −2 targets/gentoo/source/seed/strategy/local
  14. +2 −2 targets/gentoo/source/seed/strategy/remote
  15. +0 −5 targets/gentoo/source/stage1.spec
  16. +1 −1 targets/gentoo/source/stage1/strategy/local/stage1
  17. +2 −2 targets/gentoo/source/stage1/strategy/remote/stage1
  18. +2 −2 targets/gentoo/source/stage2.spec
  19. +1 −16 targets/gentoo/source/stage3.spec
  20. +2 −9 targets/gentoo/source/stage4.spec
  21. +66 −0 targets/gentoo/steps/capture/livecd.spec
  22. +2 −1 targets/gentoo/steps/capture/tar.spec
  23. +0 −7 targets/gentoo/steps/container.spec
  24. +16 −0 targets/gentoo/steps/kernel.spec
  25. +61 −0 targets/gentoo/steps/livecd.spec
  26. +9 −0 targets/gentoo/steps/stage.spec
  27. +2 −2 targets/gentoo/steps/symlink.spec
  28. +48 −0 targets/gentoo/target/README.rst
  29. +0 −37 targets/gentoo/target/container.spec
  30. +14 −0 targets/gentoo/target/files.spec
  31. +3 −7 targets/gentoo/target/stage1.spec
  32. +1 −1 targets/gentoo/target/stage2.spec
  33. +2 −7 targets/gentoo/target/stage3.spec
  34. +7 −6 targets/gentoo/target/stage4.spec
  35. +6 −4 targets/gentoo/vserver.spec
View
282 README.rst
@@ -0,0 +1,282 @@
+Metro
+=====
+
+Metro is a somewhat complex set of shell and python scripts and various files
+used to build install and LiveCD media for Gentoo Linux and its derivatives
+(like Funtoo Linux).
+
+TL;DR: `Quick Start Tutorial <http://www.funtoo.org/wiki/Metro_Quick_Start_Tutorial>`_
+
+How Metro Works
+---------------
+
+You may be wondering how Metro creates its first stage tarball. As you may have
+guessed, Metro cannot create a stage tarball out of thin air. To build a new
+stage tarball, Metro must use an existing, older stage tarball called a "seed"
+stage. This "seed" stage typically is used as the build environment for
+creating the stage we want.
+
+Metro can use two kinds of seed stages. Traditionally, Metro has used a stage3
+as a seed stage. This stage3 is then used to build a new stage1, which in turn
+is used to build a new stage2, and then a new stage3. This is generally the
+most reliable way to build Gentoo Linux or Funtoo Linux, so it's the
+recommended approach.
+
+Seeds and Build Isolation
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Another important concept to mention here is something called *build
+isolation*. Because Metro creates an isolated build environment, and the build
+environment is explicitly defined using existing, tangible entities -- a seed
+stage and a portage snapshot -- you will get consistent, repeatable results. In
+other words, the same seed stage, portage snapshot and build instructions will
+generate an essentially identical result, even if you perform the build a month
+later on someone else's workstation.
+
+Local Build
+~~~~~~~~~~~
+
+Say you wanted to build a new ``pentium4`` stage3 tarball. The recommended
+method of doing this would be to grab an existing ``pentium4`` stage3 tarball
+to use as your seed stage. Metro will be told to use this existing ``pentium4``
+stage3 to build a new stage1 for the same ``pentium4``. For this process, the
+generic ``pentium4`` stage3 would provide the *build environment* for creating
+our new stage1. Then, the new stage1 would serve as the build environment for
+creating the new ``pentium4`` stage2. And the new ``pentium4`` stage2 would
+serve as the build environment for creating the new ``pentium4`` stage3.
+
+In the Metro terminology this is called a *local build*, which means a stage3
+of a given architecture is used to seed a brand new build of the same
+architecture.
+
+A week later, you may want to build a brand new ``pentium4`` stage3 tarball. Rather
+than starting from the original ``pentium4`` stage3 again, you'd probably configure
+Metro to use the most-recently-built ``pentium4`` stage3 as the seed. Metro has
+built-in functionality to make this easy, allowing it to easily find and track
+the most recent stage3 seed available.
+
+Remote Build
+~~~~~~~~~~~~
+
+Metro can also perform a *remote build*, where a stage3 of a different, but binary
+compatible, architecture is used as a seed to build a different architecture
+stage3.
+
+Tailored Build
+~~~~~~~~~~~~~~
+
+Last, it's also worthy noting that both in local and remote builds, Metro can
+be configured to add and/or remove individual packages to the final tarball.
+Let's say you can't live without app-misc/screen, at the end of this tutorial,
+we will show how to have your tailored stage3 to include it.
+
+Metro Data Model
+----------------
+
+The Metro Data Model has been designed to provide you with an optimal way to
+organize build data.
+
+Here are the primary goals for the data model:
+
+* Provide useful ways to organize data
+* Use mechanisms and syntax that maximize maintainability of the data over
+ time
+* Reduce and (ideally) eliminate side-effects at every opportunity
+
+To attain these goals, Metro uses a functional data model, where an element
+(variable) can be defined only once, and cannot be redefined.
+
+By default, the Metro parser operates in "strict" mode, which means that it
+will throw an error if a variable has been referenced that has not been
+defined. This "strict" mode is actually very useful in catching errors that
+might otherwise go unnoticed and result in broken builds.
+
+In addition, the Metro parser was designed so that the order in which data
+elements are defined is not important, even if they reference one another. This
+was done to eliminate side-effects related to data ordering, where changing the
+order in which things are defined in a file can change the behavior of or break
+your code.
+
+First Look
+~~~~~~~~~~
+
+Here is some sample Metro data::
+
+ path: /usr/bin
+
+Above, we have defined the element ``path`` to have the value ``/usr/bin``.
+``path`` is a single-line element, and the Metro parser takes care of trimming
+any trailing whitespace that may be on the line. You can also define
+single-line elements that have values that consist of multiple
+whitespace-separated values::
+
+ options: ccache replace
+
+Sometimes, you need to define an element but leave it blank. To do this, don't
+specify any values after the colon::
+
+ options:
+
+In Metro, the / character is used to delineate various classes of elements, as
+follows::
+
+ path/mirror: /home/mirror/linux
+ path/mirror/snapshot: /home/mirror/linux/snapshots
+ path/metro: /usr/lib/metro
+
+Above, we see the proper Metro convention for specifying paths. Each path has a
+prefix of ``path/``. We have a ``path/mirror`` element but also have a
+path/mirror/snapshot element. The ``/`` is used to organize our data into
+logical groups. This is not enforced by Metro but is presented here as a best
+practice.
+
+The data above could also be represented using a section annotation, as
+follows::
+
+ [section path]
+
+ mirror: /home/mirror/linux
+ mirror/snapshot: /home/mirror/linux/snapshots
+ metro: /usr/lib/metro
+
+Above, the ``[section path]`` line is a *section annotation*, and it tells the
+Metro parser that the ``path/`` prefix should be applied to all following data
+elements. A section annotation is in effect until another section annotation
+is encountered by the parser.
+
+While our data above is getting more organized, there is some redundancy in our
+data, which generally isn't a good thing. Here's an example of how to make our
+data a bit more compact::
+
+ [section path]
+
+ mirror: /home/mirror/linux
+ mirror/snapshot: $[path/mirror]/snapshots
+ metro: /usr/lib/metro
+
+Above, we have used an *element reference* of ``$[path/mirror]`` to reference
+our path/mirror element. What this means is that ``path/snapshot`` will have a
+value of ``/home/mirror/linux/snapshots``.
+
+Also, it's worth pointing out that we could just have well written::
+
+ [section path]
+
+ mirror/snapshot: $[path/mirror]/snapshots
+ mirror: /home/mirror/linux
+ metro: /usr/lib/metro
+
+In other words, it's perfectly OK to use the element reference of
+``$[path/mirror]`` on a line before the actual definition of ``path/mirror``.
+Metro doesn't care about the order in which data is defined.
+
+Metro provides another way to organize your data in an efficient way. Supposing
+that you had a lot of ``path/mirror``-related data, then it might be useful to
+organize your data as follows::
+
+ [section path]
+
+ metro: /usr/lib/metro
+
+ [section path/mirror]
+
+ : /home/mirror/linux
+ snapshot: $[]/snapshot
+ source: $[]/$[source/subarch]/funtoo-$[source/subarch]-$[source/version]/$[source/name].tar.bz2
+
+Above, we have used two new parser features. Inside ``[section path/mirror]``,
+we can define the ``path/mirror`` element itself by using a blank element name,
+followed by a ``:``. The next parser feature we see above is that we can use
+``$[]`` to reference the value of the ``path/mirror`` value. ``$[]`` will
+always reference the value of the element specified in the section annotation.
+Also note that as of Metro 1.1, ``$[:]`` can be used as an alternate form of
+``$[]``. In addition, as of Metro 1.2.4, ``$[:foo]`` can be used as an
+alternate form of ``$[section-name/foo]``.
+
+Collect Annotations
+~~~~~~~~~~~~~~~~~~~
+
+Many scripting languages have the notion of an "include" file, or "importing"
+additional data from a remote file. Metro has this concept as well, but it is
+implemented in a somewhat different way. You can tell Metro to include data
+from another file by using a *collect annotation*.
+
+A collect annotation looks like this::
+
+ [collect $[path/metro]/myfile.txt]
+
+Now, we called these things "collect annotations" for a reason - in Metro, they
+work slightly different than most languages implement ``include`` and
+``import``. The main difference is that in Metro, a collect annotation does not
+happen right away. Instead, Metro will add the file to be collected (in this
+case, that would be the file ``/usr/lib/metro/myfile.txt``, or whatever
+``$[path/metro]/myfile.txt`` evaluates to) to a collection queue.
+
+This means that Metro will read in the contents of the file at some point in
+time, and the data in the file will be available to you by the time the parsing
+is complete. But because Metro doesn't care about the order in which data is
+defined, it doesn't have the same concept of "read in the data - right now!"
+that an include or import statement does in other languages.
+
+Conditional Collect Annotations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Metro no longer officially supports conditional collect annotations; however,
+simple collect annotations can be used to make conditional decisions in Metro,
+as follows::
+
+ [collect ./snapshots/$[snapshot/type]]
+
+Above, Metro will collect from a file based on the value of the
+``$[snapshot/type]`` element. This allows for varying definitions of elements
+to exist dependent on the value of ``$[snapshot/type]``.
+
+Above, Metro will raise an exception if ``$[snapshot/type]`` is undefined or has a
+value that does not map to a file on disk. If it is possible that
+``$[snapshot/type]`` may not be defined, use the following format::
+
+ [collect ./snapshots/$[snapshot/type:zap]]
+
+Using the ``:zap`` modifier, the entire collect argument will be replaced with
+the empty string if ``$[snapshot/type]`` is undefined. If Metro is asked to
+collect an empty string, it will not throw an exception. So this is a handy way
+to conditionally disable collection of a file. But please note that for all
+non-null values of ``$[snapshot/type]``, a corresponding file must exist on
+disk in ``./snapshots/`` or Metro will throw an exception. ``:zap`` is
+explained in more detail in the "Special Variable Expansion" section, below.
+
+Multi-line elements
+~~~~~~~~~~~~~~~~~~~
+
+Metro supports multi-line elements and they are the foundation of Metro's
+template engine. A multi-line element can be defined as follows, by using
+square brackets to delimit multi-line data::
+
+ myscript: [
+ #!/bin/bash
+ echo $*
+ ]
+
+The terminating closing square bracket should be on a line all by itself.
+
+One of the very useful things about multi-line elements is that they support
+Metro element references::
+
+ myscript: [
+ #!/bin/bash
+ echo Metro's path/metro setting is $[path/metro].
+ ]
+
+In the above multi-line element, the ``$[path/metro]`` reference will be expanded
+to contain the appropriate value of the element. It is possible to expand
+single-line elements inside multi-line elements simply by referencing them
+using a dollar sign and square brackets.
+
+Metro also allows you to expand multi-line elements inside other multi-line
+elements. Here's an example of how that works::
+
+ myscript: [
+ #!/bin/bash
+ $[[steps/setup]]
+ echo Hi There :)
+ ]
View
13 etc/builds/funtoo-current/build.conf
@@ -1,6 +1,6 @@
[collect ../../fslayouts/funtoo/layout.conf]
-[section local]
+[section release]
author: Daniel Robbins <drobbins@funtoo.org>
@@ -60,4 +60,15 @@ target: gentoo
snapshot: snapshot
+[section files]
+
+motd/trailer: [
+
+ >>> Send suggestions, improvements, bug reports relating to...
+
+ >>> This release: $[release/author]
+ >>> Funtoo Linux (general): Funtoo Linux (http://www.zentoo.org)
+ >>> Gentoo Linux (general): Gentoo Linux (http://www.gentoo.org)
+]
+
[collect ../../multi-targets/$[multi/mode:zap]]
View
13 etc/builds/funtoo-experimental/build.conf
@@ -1,6 +1,6 @@
[collect ../../fslayouts/funtoo/layout.conf]
-[section local]
+[section release]
author: Daniel Robbins <drobbins@funtoo.org>
@@ -60,4 +60,15 @@ target: gentoo
snapshot: snapshot
+[section files]
+
+motd/trailer: [
+
+ >>> Send suggestions, improvements, bug reports relating to...
+
+ >>> This release: $[release/author]
+ >>> Funtoo Linux (general): Funtoo Linux (http://www.zentoo.org)
+ >>> Gentoo Linux (general): Gentoo Linux (http://www.gentoo.org)
+]
+
[collect ../../multi-targets/$[multi/mode:zap]]
View
13 etc/builds/funtoo-stable/build.conf
@@ -1,6 +1,6 @@
[collect ../../fslayouts/funtoo/layout.conf]
-[section local]
+[section release]
author: Daniel Robbins <drobbins@funtoo.org>
@@ -60,4 +60,15 @@ target: gentoo
snapshot: snapshot
+[section files]
+
+motd/trailer: [
+
+ >>> Send suggestions, improvements, bug reports relating to...
+
+ >>> This release: $[release/author]
+ >>> Funtoo Linux (general): Funtoo Linux (http://www.zentoo.org)
+ >>> Gentoo Linux (general): Gentoo Linux (http://www.gentoo.org)
+]
+
[collect ../../multi-targets/$[multi/mode:zap]]
View
12 etc/builds/gentoo-stable/build.conf
@@ -1,6 +1,6 @@
[collect ../../fslayouts/funtoo/layout.conf]
-[section local]
+[section release]
author: Daniel Robbins <drobbins@funtoo.org>
@@ -50,4 +50,14 @@ target: gentoo
snapshot: snapshot
extras:
+[section files]
+
+motd/trailer: [
+
+ >>> Send suggestions, improvements, bug reports relating to...
+
+ >>> This release: $[release/author]
+ >>> Gentoo Linux (general): Gentoo Linux (http://www.gentoo.org)
+]
+
[collect ../../multi-targets/$[multi/mode:zap]]
View
14 etc/fslayouts/funtoo/layout.conf
@@ -26,16 +26,14 @@ snapshot/subpath: $[]/$[target/build]/snapshots
source/subpath: $[]/$[source/build]/$[target/arch_desc:zap]/$[source/subarch:zap]/$[source/version]
target/subpath: $[]/$[target/build]/$[target/arch_desc:zap]/$[target/subarch:zap]/$[target/version]
-control: $[]/$[target/build]/$[target/arch_desc:zap]/$[target/subarch:zap]/.control
-
source/control: $[]/$[source/build]/$[target/arch_desc:zap]/$[source/subarch:zap]/.control
+target/control: $[]/$[target/build]/$[target/arch_desc:zap]/$[target/subarch:zap]/.control
-# "current" symlink:
-stage/link: $[]/$[target/build]/$[target/arch_desc]/$[target/subarch]/$[target/name/current].tar.$[target/compression]
-stage/link/dest: $[target/version]/$[target/name].tar.$[target/compression]
+target: $[:target/subpath]/$[:target/basename]
+target/link: $[]/$[target/build]/$[target/arch_desc]/$[target/subarch]/$[:target/current]
+target/link/dest: $[target/version]/$[:target/basename]
[section strategy]
-seed: << $[path/mirror/control:zap]/strategy/seed
-build: << $[path/mirror/control:zap]/strategy/build
-
+seed: << $[path/mirror/target/control:zap]/strategy/seed
+build: << $[path/mirror/target/control:zap]/strategy/build
View
3 etc/metro.conf
@@ -16,10 +16,11 @@ work: $[path/tmp]/work/$[target/build]/$[target/name]
[section path/cache]
: $[path/tmp]/cache
-build: $[]/build/$[target/build]/$[target/name]
git: $[]/cloned-repositories
+build: $[]/build/$[target/build]/$[target/name]
package: $[path/cache/build]/package
compiler: $[path/cache/build]/compiler
+kernel: $[path/cache/build]/kernel
probe: $[path/cache/build]/probe
# Mirror Paths - where to find required files and where to put created files
View
1 modules/targets.py
@@ -168,6 +168,7 @@ def __init__(self, settings):
for key, name, dest in [
[ "path/cache/compiler", "cache/compiler", "/var/tmp/cache/compiler" ] ,
[ "path/cache/package", "cache/package", "/var/tmp/cache/package" ] ,
+ [ "path/cache/kernel", "cache/kernel", "/var/tmp/cache/kernel" ] ,
[ "path/cache/probe", "probe", "/var/tmp/cache/probe" ] ]:
if self.settings.has_key(skey) and name in self.settings[skey].split():
if not self.settings.has_key(key):
View
10 targets/gentoo/lxc.spec
@@ -1,13 +1,15 @@
[collect ./source/stage3.spec]
-[collect ./target/container.spec]
+[collect ./target/stage4.spec]
+[collect ./steps/container.spec]
[collect ./steps/capture/tar.spec]
+[section stage4]
+
+target/name: lxc
+
[section target]
-name: lxc-$[:subarch]-$[:build]-$[:version]
sys: lxc
-realname: Linux Containers
-url: http://lxc.sourceforge.net
[section steps]
View
10 targets/gentoo/openvz.spec
@@ -1,13 +1,15 @@
[collect ./source/stage3.spec]
-[collect ./target/container.spec]
+[collect ./target/stage4.spec]
+[collect ./steps/container.spec]
[collect ./steps/capture/tar.spec]
+[section stage4]
+
+target/name: openvz
+
[section target]
-name: openvz-$[:build]-$[:subarch]-$[:version]
sys: openvz
-realname: OpenVZ
-url: http://www.openvz.org
[section steps]
View
51 targets/gentoo/source/README.rst
@@ -0,0 +1,51 @@
+Source Specifications
+=====================
+
+Source specifications define the source type, version, subarch, build name and
+the location of the source archive. The following source types exist:
+
+seed
+----
+
+The seed source is usually used to build a stage1 target. A stage1 is not
+considered a stage3 derivative, because it may use a *remote* stage3 as a seed
+(ie. build and subarch do not match the target). True stage3 derivatives use a
+stage3 that has the same build, subarch and version as the target.
+
+When building a stage1, we're always going to use a stage3 as a seed though. If
+``strategy/build`` is *local*, we'll grab a local stage3. If it's *remote*,
+we're going to use a remote stage3.
+
+stage1
+------
+
+The stage1 source is usually used to build a stage2 target. If
+``strategy/build`` is *local*, we'll grab a local stage1. If it's *remote*,
+we're going to use a remote stage1.
+
+stage2
+------
+
+The stage2 source is usually used to build a stage3 target. Not all stage3
+targets are stage2 derivatives though. A target can be both a stage3 generator
+and a stage3 derivative -- stage3-freshen and stage3-quick are two examples.
+
+stage3
+------
+
+The stage3 source is used for all stage3 derivatives. Stage3 derivatives are
+those targets that are generated directly from a stage3, and include
+stage3-freshen, stage3-quick, stage4, container or livecd media.
+
+When building from a stage3, we simply use the stage3 with matching build,
+subarch and version. To build from a different subarch/version use the seed
+source. This is usually only done to build stage1 targets.
+
+For a regular full build, the source/version and target/version will be
+equal. However, for a stage3-freshen build, we will use the last-built
+stage3 as a seed.
+
+stage4
+------
+
+tbd
View
11 targets/gentoo/source/seed.spec
@@ -1,18 +1,7 @@
[collect ./common.spec]
-# A stage1 is no longer considered a stage3 derivative, because it may use a
-# "remote" (ie. not in the current build/subarch directory) stage3 as a seed.
-# True stage3 derivatives use a stage3 that has the same build, subarch and
-# version as the target.
-
[section source]
: stage3
name: $[]-$[:subarch]-$[:build]-$[:version]
-
-# When building a stage1, we're always going to use a stage3 as a seed. If
-# $[strategy/build] is "local", we'll grab a local stage3. If it's "remote",
-# we're going to use a remote stage3. This collect annotation makes this
-# happen:
-
[collect ./seed/strategy/$[strategy/build]]
View
4 targets/gentoo/source/seed/strategy/local
@@ -1,5 +1,5 @@
[section source]
-subarch: $[target/subarch]
build: $[target/build]
-version: << $[path/mirror/control]/version/stage3
+subarch: $[target/subarch]
+version: << $[path/mirror/target/control]/version/stage3
View
4 targets/gentoo/source/seed/strategy/remote
@@ -1,5 +1,5 @@
[section source]
-build: << $[path/mirror/control]/remote/build
-subarch: << $[path/mirror/control]/remote/subarch
+build: << $[path/mirror/target/control]/remote/build
+subarch: << $[path/mirror/target/control]/remote/subarch
version: << $[path/mirror/source/control]/version/stage3
View
5 targets/gentoo/source/stage1.spec
@@ -4,9 +4,4 @@
: stage1
name: $[]-$[:subarch]-$[:build]-$[:version]
-
-# The collect annotation below will allow us to grab a remote stage1
-# for our build if $[strategy/build] is "remote" and $[strategy/seed]
-# is "stage1". In all other cases, we use a local stage1 as source.
-
[collect ./stage1/strategy/$[strategy/build]/$[strategy/seed]]
View
2 targets/gentoo/source/stage1/strategy/local/stage1
@@ -1,5 +1,5 @@
[section source]
-version: $[target/version]
build: $[target/build]
subarch: $[target/subarch]
+version: $[target/version]
View
4 targets/gentoo/source/stage1/strategy/remote/stage1
@@ -1,5 +1,5 @@
[section source]
-build: << $[path/mirror/control]/remote/build
-subarch: << $[path/mirror/control]/remote/subarch
+build: << $[path/mirror/target/control]/remote/build
+subarch: << $[path/mirror/target/control]/remote/subarch
version: << $[path/mirror/source/control]/version/stage1
View
4 targets/gentoo/source/stage2.spec
@@ -4,6 +4,6 @@
: stage2
name: $[]-$[:subarch]-$[:build]-$[:version]
-version: $[target/version]
-subarch: $[target/subarch]
build: $[target/build]
+subarch: $[target/subarch]
+version: $[target/version]
View
17 targets/gentoo/source/stage3.spec
@@ -1,24 +1,9 @@
[collect ./common.spec]
-# This file defines common settings for all stage3 derivatives. Stage3
-# derivatives are those targets that are generated directly from a stage3, and
-# include stage3-freshen, stage3-quick, stage4 and openvz. A target can be both
-# a stage3 generator and a stage3 derivative -- stage3-freshen and stage3-quick
-# are two examples.
-
[section source]
: stage3
name: $[]-$[:subarch]-$[:build]-$[:version]
-
-# When building from a stage3, we simply use the stage3 with matching
-# build, subarch and version:
-
build: $[target/build]
subarch: $[target/subarch]
-
-# For a regular full build, the source/version and target/version will be
-# equal. However, for a stage3-freshen build, we will use the last-built
-# stage3 as a seed:
-
-version: << $[path/mirror/control]/version/stage3
+version: << $[path/mirror/target/control]/version/stage3
View
11 targets/gentoo/source/stage4.spec
@@ -1,16 +1,9 @@
[collect ./common.spec]
-# This file defines common settings for all stage4 derivatives. Stage4
-# derivatives are those targets that are generated directly from a stage4, and
-# include live media, ec2 and ova images.
-
[section source]
+: $[stage4/source/name]
name: $[]-$[:subarch]-$[:build]-$[:version]
-
-# When building from a stage4, we simply use the stage4 with matching
-# build, subarch and version:
-
build: $[target/build]
subarch: $[target/subarch]
-version: $[target/version]
+version: << $[path/mirror/target/control]/version/stage4/$[stage4/source/name]
View
66 targets/gentoo/steps/capture/livecd.spec
@@ -0,0 +1,66 @@
+[section path/mirror]
+
+target/basename: $[target/name].iso
+target/current: $[target/name/current].iso
+
+[section steps]
+
+capture: [
+#!/bin/bash
+
+# create cd root
+cdroot=$[path/mirror/target]
+cdroot=${cdroot%.*}
+if [ ! -d $cdroot ]
+then
+ install -d $cdroot || exit 1
+fi
+touch $cdroot/livecd
+
+# create livecd filesystem with squashfs
+squashout=$cdroot/image.squashfs
+mksquashfs $[path/chroot/stage] $squashout
+if [ $? -ge 1 ]
+then
+ rm -f "$squashout" "$cdroot" "$[path/mirror/target]"
+ exit 1
+fi
+
+# copy bootloader and kernel
+install -d $cdroot/isolinux || exit 1
+cp "$[livecd/isolinux/binfile]" "$cdroot/isolinux" || exit 1
+cp -T $[path/chroot/stage]/boot/kernel* $cdroot/isolinux/kernel || exit 1
+cp -T $[path/chroot/stage]/boot/initramfs* $cdroot/isolinux/initramfs || exit 1
+cp -T $[path/chroot/stage]/boot/System.map* $cdroot/isolinux/System.map || exit 1
+
+cat > $cdroot/isolinux/isolinux.cfg << "EOF"
+prompt 1
+default $[target/build]
+
+label $[target/build]
+ kernel kernel
+ append root=/dev/ram0 looptype=squashfs loop=/image.squashfs cdroot dosshd nogpm nosound nox nonfs quiet
+ append root=/dev/ram0 looptype=squashfs loop=/image.squashfs cdroot dosshd nogpm nosound nox nonfs quiet passwd=$[livecd/passwd:zap]
+ initrd initramfs
+EOF
+
+# install memtest boot option
+if test "$[livecd/memtest?]" = "yes" && test -f "$[livecd/memtest:lax]"; then
+ cp "$[livecd/memtest]" "$cdroot/isolinux/$(basename "$[livecd/memtest]")"
+ cat >> $cdroot/isolinux/isolinux.cfg << EOF
+
+label memtest
+ kernel $(basename "$[livecd/memtest]")
+EOF
+fi
+
+# create iso image
+mkisofs -l \
+ -o $[path/mirror/target] \
+ -b isolinux/$(basename "$[livecd/isolinux/binfile]") \
+ -c isolinux/boot.cat \
+ -no-emul-boot -boot-load-size 4 -boot-info-table \
+ $cdroot/ || exit 1
+
+rm -rf $cdroot || exit 1
+]
View
3 targets/gentoo/steps/capture/tar.spec
@@ -1,6 +1,7 @@
[section path/mirror]
-target: $[:target/subpath]/$[target/name].tar.$[target/compression]
+target/basename: $[target/name].tar.$[target/compression]
+target/current: $[target/name/current].tar.$[target/compression]
[section steps]
View
7 targets/gentoo/steps/container.spec
@@ -59,12 +59,6 @@ cat > /etc/conf.d/hostname << EOF || exit 5
hostname=${myhost}
EOF
-# motd
-echo "Creating motd..."
-cat > /etc/motd << "EOF"
-$[[files/motd]]
-EOF
-
# cleanup
rm -rf /etc/ssh/ssh_host* /var/tmp/* /var/log/* /tmp/* /root/.bash_history /etc/resolv.conf
@@ -80,5 +74,4 @@ echo "Root password check: PASSED"
# tty must exist
[ ! -e /dev/tty ] && exit 16
echo "/dev/tty check: PASSED"
-echo "$[target/realname] script complete."
]
View
16 targets/gentoo/steps/kernel.spec
@@ -0,0 +1,16 @@
+[section steps/kernel]
+
+build: [
+echo > /etc/fstab || exit 1
+emerge $eopts --noreplace sys-kernel/genkernel $[livecd/kernel/package] || exit 1
+genkernel $[livecd/kernel/opts:lax] \
+ --cachedir=/var/tmp/cache/kernel \
+ --modulespackage=/var/tmp/cache/kernel/modules.tar.bz2 \
+ --minkernpackage=/var/tmp/cache/kernel/kernel-initrd.tar.bz2 \
+ all || exit 1
+]
+
+clean: [
+emerge -C sys-kernel/genkernel $[livecd/kernel/package] || exit 1
+rm -rf /usr/src/linux-* /usr/src/linux || exit 1
+]
View
61 targets/gentoo/steps/livecd.spec
@@ -0,0 +1,61 @@
+[section steps]
+
+livecd: [
+emerge $eopts --noreplace app-misc/livecd-tools net-dialup/mingetty net-misc/dhcpcd sys-apps/hwsetup || exit 1
+
+# setup init scripts
+rc-update del keymaps boot
+rc-update del netmount default
+
+rc-update add autoconfig default
+rc-update add fixinittab default
+
+# permit root login via ssh
+if [ -e /etc/ssh/sshd_config ]
+then
+ sed -i -e 's:^#PermitRootLogin\ yes:PermitRootLogin\ yes:' \
+ /etc/ssh/sshd_config
+fi
+
+# set timezone
+rm -rf /etc/localtime
+cp /usr/share/zoneinfo/UTC /etc/localtime || exit 1
+
+# set the hostname
+echo 'hostname=livecd' > /etc/conf.d/hostname
+echo '127.0.0.1 livecd.local livecd localhost' > /etc/hosts.orig
+
+# try to get a network address via dhcp
+echo 'dhcpcd eth0' > /etc/ifup.eth0
+
+# for hwsetup
+mkdir -p /etc/sysconfig
+
+# make sure we have the latest pci, usb and hotplug ids
+[ -x /sbin/update-pciids ] && /sbin/update-pciids
+[ -x /sbin/update-usbids ] && /sbin/update-usbids
+[ -x /usr/sbin/update-pciids ] && /usr/sbin/update-pciids
+[ -x /usr/sbin/update-usbids ] && /usr/sbin/update-usbids
+
+if [ -d /usr/share/hwdata ]
+then
+ # If we have uncompressed pci and usb ids files, symlink them.
+ [ -f /usr/share/misc/pci.ids ] && [ -f /usr/share/hwdata/pci.ids ] && \
+ rm -f /usr/share/hwdata/pci.ids && ln -s /usr/share/misc/pci.ids \
+ /usr/share/hwdata/pci.ids
+ [ -f /usr/share/misc/usb.ids ] && [ -f /usr/share/hwdata/usb.ids ] && \
+ rm -f /usr/share/hwdata/usb.ids && ln -s /usr/share/misc/usb.ids \
+ /usr/share/hwdata/usb.ids
+ # If we have compressed pci and usb files, we download our own copies.
+ [ -f /usr/share/misc/pci.ids.gz ] && [ -f /usr/share/hwdata/pci.ids ] && \
+ rm -f /usr/share/hwdata/pci.ids && wget -O /usr/share/hwdata/pci.ids \
+ http://pciids.sourceforge.net/v2.2/pci.ids
+ [ -f /usr/share/misc/usb.ids.gz ] && [ -f /usr/share/hwdata/usb.ids ] && \
+ rm -f /usr/share/hwdata/usb.ids && wget -O /usr/share/hwdata/usb.ids \
+ http://www.linux-usb.org/usb.ids
+fi
+
+# save some space
+emerge --depclean || exit 1
+rm -rf /usr/lib/debug || exit 1
+]
View
9 targets/gentoo/steps/stage.spec
@@ -119,7 +119,10 @@ if [ "$[target]" != "stage1" ] && [ -e /usr/bin/ccache ]
then
emerge -C dev-util/ccache || exit 1
fi
+
emerge -C $[emerge/packages/clean:zap] || exit 2
+
+# systemd compatible os-release file
cat <<EOF > /etc/os-release
ID=$[release/name/id:zap]
NAME="$[release/name:zap]"
@@ -129,6 +132,12 @@ VERSION="$[release/version:zap]"
VERSION_ID=$[release/version/id:zap]
ANSI_COLOR="$[release/color:zap]"
EOF
+
+# motd
+echo "Creating motd..."
+cat > /etc/motd << "EOF"
+$[[files/motd]]
+EOF
]
clean: [
View
4 targets/gentoo/steps/symlink.spec
@@ -2,6 +2,6 @@
ok/symlink: [
#!/bin/bash
-rm -f $[path/mirror/stage/link]
-ln -s $[path/mirror/stage/link/dest] $[path/mirror/stage/link]
+rm -f $[path/mirror/target/link]
+ln -s $[path/mirror/target/link/dest] $[path/mirror/target/link]
]
View
48 targets/gentoo/target/README.rst
@@ -0,0 +1,48 @@
+Target Specifications
+=====================
+
+Target specifications define the target type, version, subarch, build name and
+the location of the target archive. The following target types exist:
+
+stage1
+------
+
+This target is used to build a stage1 and is usually used together with the
+seed source. After a successful stage1 build, metro will update the
+``.control/version/stage1`` file. This file records the version of the last
+successful stage1 build.
+
+stage2
+------
+
+This target is used to build a stage2 and is usually used together with the
+stage1 source.
+
+stage3
+------
+
+This target is used to build a stage3 and is usually used together with the
+stage2 target. Not all stage3 targets are stage2 derivatives though. A target
+can be both a stage3 generator and a stage3 derivative -- stage3-freshen and
+stage3-quick are two examples.
+
+After a successful stage3 build, metro will update the
+``.control/version/stage3`` file. This file records the version of the last
+successful stage3 build.
+
+stage4
+------
+
+This target is used to produce various specialized images such as preconfigured
+webserver or database images and is usually used together with the stage3
+source. It is also possible to build from a stage4 source in case the target is
+just a superset of the source.
+
+After each successful stage4 build, metro will update a file in the
+``.control/version/stage4`` directory. This file records the version of the
+last successful stage4 build.
+
+container
+---------
+
+tbd
View
37 targets/gentoo/target/container.spec
@@ -1,37 +0,0 @@
-[collect ../steps/unpack.spec]
-[collect ../steps/container.spec]
-
-[section target]
-
-class: chroot
-
-[section path]
-
-chroot: $[path/work]
-
-[section steps]
-
-unpack: [
-#!/bin/bash
-$[[steps/unpack/source]]
-]
-
-[section files]
-
-motd: [
-
- >>> Template: $[target/name]
- >>> Technology: $[target/realname]
- >>> Version: $[target/version]
- >>> Created by: $[local/author]
-
- >>> Send suggestions, improvements, bug reports relating to...
-
- >>> This template: $[local/author]
- >>> Funtoo Linux (general): Funtoo Linux (http://www.funtoo.org)
- >>> Gentoo Linux (general): Gentoo Linux (http://www.gentoo.org)
- >>> Container technology: $[target/url]
-
- NOTE: This message can be removed by deleting /etc/motd.
-
-]
View
14 targets/gentoo/target/files.spec
@@ -45,3 +45,17 @@ for x in ["http_proxy","ftp_proxy","RSYNC_PROXY"]:
print "# "+x+" is not set"
?>
]
+
+[section files]
+
+motd: [
+$[[files/motd/extra:lax]]
+
+ >>> Release: $[target/name]
+ >>> Version: $[target/version]
+ >>> Created by: $[release/author]
+$[[files/motd/trailer:lax]]
+
+ NOTE: This message can be removed by deleting /etc/motd.
+
+]
View
10 targets/gentoo/target/stage1.spec
@@ -2,17 +2,13 @@
[section target]
-name: $[]-$[:subarch]-$[:build]-$[:version]
+name: stage1-$[:subarch]-$[:build]-$[:version]
[section trigger]
ok/run: [
#!/bin/bash
-# Since we've completed a successful stage1 build, we will update our
-# .control/version/stage1 file. This file records the version of the last
-# successful stage1 build.
-
-install -d $[path/mirror/control]/version || exit 1
-echo "$[target/version]" > $[path/mirror/control]/version/stage1 || exit 1
+install -d $[path/mirror/target/control]/version || exit 1
+echo "$[target/version]" > $[path/mirror/target/control]/version/stage1 || exit 1
]
View
2 targets/gentoo/target/stage2.spec
@@ -2,4 +2,4 @@
[section target]
-name: $[]-$[:subarch]-$[:build]-$[:version]
+name: stage2-$[:subarch]-$[:build]-$[:version]
View
9 targets/gentoo/target/stage3.spec
@@ -11,13 +11,8 @@ name/current: stage3-current
ok/run: [
#!/bin/bash
-# Since we've completed a successful stage3 build, we will update our
-# .control/version/stage3 file. This file records the version of the last
-# successful stage3 build.
-
-
-install -d $[path/mirror/control]/version || exit 1
-echo "$[target/version]" > $[path/mirror/control]/version/stage3 || exit 1
+install -d $[path/mirror/target/control]/version || exit 1
+echo "$[target/version]" > $[path/mirror/target/control]/version/stage3 || exit 1
$[[trigger/ok/symlink]]
]
View
13 targets/gentoo/target/stage4.spec
@@ -1,18 +1,19 @@
-# This file defines common settings for all stage4 generators. Stage4
-# generators are targets that build on top of a stage3 to produce various
-# specialized images such as a webserver, database or container images.
-
[collect ./stage.spec]
[collect ../steps/symlink.spec]
[section target]
-name: $[stage4/name]-$[:subarch]-$[:build]-$[:version]
-name/current: $[stage4/name]-current
+name: $[stage4/target/name]-$[:subarch]-$[:build]-$[:version]
+name/current: $[stage4/target/name]-current
[section trigger]
ok/run: [
+#!/bin/bash
+
+install -d $[path/mirror/target/control]/version/stage4 || exit 1
+echo "$[target/version]" > $[path/mirror/target/control]/version/stage4/$[stage4/target/name] || exit 1
+
$[[trigger/ok/symlink]]
]
View
10 targets/gentoo/vserver.spec
@@ -1,13 +1,15 @@
[collect ./source/stage3.spec]
-[collect ./target/container.spec]
+[collect ./target/stage4.spec]
+[collect ./steps/container.spec]
[collect ./steps/capture/tar.spec]
+[section stage4]
+
+target/name: vserver
+
[section target]
-name: vserver-$[:subarch]-$[:build]-$[:version]
sys: vserver
-realname: Linux-VServer
-url: http://linux-vserver.org
[section steps]

0 comments on commit 85b9310

Please sign in to comment.
Something went wrong with that request. Please try again.