revisor-devel June 2009

revisor-devel@lists.stg.fedorahosted.org

2 participants
8 discussions

po/es.po
by Transifex System User 19 Jun '09

19 Jun '09

po/es.po | 145 ++++++++++++++++++++++++++++++++------------------------------- 1 file changed, 75 insertions(+), 70 deletions(-) New commits: commit d08b3e7cf9f0beb846317ac57d661ae7ff5b4855 Author: logan <logan(a)fedoraproject.org> Date: Fri Jun 19 18:51:34 2009 +0000 Sending translation for Spanish diff --git a/po/es.po b/po/es.po index 5190b1d..b14dfc0 100644 --- a/po/es.po +++ b/po/es.po @@ -7,8 +7,8 @@ msgid "" msgstr "" "Project-Id-Version: revisor\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2009-04-27 19:09+0000\n" -"PO-Revision-Date: 2009-04-27 19:01-0300\n" +"POT-Creation-Date: 2009-06-19 14:15+0000\n" +"PO-Revision-Date: 2009-06-19 15:50-0300\n" "Last-Translator: Héctor Daniel Cabrera <h.daniel.cabrera(a)gmail.com>\n" "Language-Team: fedora spanish <fedora-trans-es(a)redhat.com>\n" "MIME-Version: 1.0\n" @@ -1491,127 +1491,127 @@ msgstr "Descargando Paquetes Fuente" msgid "Downloading Packages" msgstr "Descargando Paquetes" -#: ../revisor/base.py:787 +#: ../revisor/base.py:793 #, python-format msgid "Overriding auto package selection with user package selection for %s..." msgstr "Superponiendo la selección de paquetes automática con la selección de paquetes del usuario para %s..." -#: ../revisor/base.py:800 +#: ../revisor/base.py:806 #, python-format msgid "Adding required package %s-%s:%s-%s.%s" msgstr "Agregandos paquete requerido %s-%s:%s-%s.%s" #. This list has already been resolved -#: ../revisor/base.py:803 +#: ../revisor/base.py:809 #, python-format msgid "%s. This is a required package." msgstr "%s. Este es un paquete requerido." -#: ../revisor/base.py:815 +#: ../revisor/base.py:821 #, python-format msgid "Adding suggested package %s-%s:%s-%s.%s" msgstr "Agregando paquete sugerido %s-%s:%s-%s.%s" -#: ../revisor/base.py:826 +#: ../revisor/base.py:832 #, python-format msgid "Adding all-arch package %s-%s:%s-%s.%s" msgstr "Añadiendo paquete de arq. independiente %s-%s:%s-%s.%s" -#: ../revisor/base.py:863 -#: ../revisor/base.py:889 +#: ../revisor/base.py:869 +#: ../revisor/base.py:895 msgid "Did not succeed in adding in all required packages" msgstr "No se tuvo éxito en agregar todos los paquetes requeridos" -#: ../revisor/base.py:897 +#: ../revisor/base.py:903 msgid "Populating statistics" msgstr "Reuniendo estadísticas" -#: ../revisor/base.py:913 +#: ../revisor/base.py:919 #, python-format msgid "Package %s-%s:%s-%s.%s does not seem to have a archivesize header" msgstr "El paquete %s-%s:%s-%s.%s no parece tener una cabecera de tamaño de archivo" -#: ../revisor/base.py:921 +#: ../revisor/base.py:927 #, python-format msgid "Package %s-%s:%s-%s.%s does not seem to have a installedsize header" msgstr "El paquete %s-%s:%s-%s.%s no parece tener una cabecera de tamaño de instalación" -#: ../revisor/base.py:929 +#: ../revisor/base.py:935 #, python-format msgid "Package %s-%s:%s-%s.%s does not seem to have a packagesize header" msgstr "El paquete %s-%s:%s-%s.%s no parece tener una cabecera de tamaño de paquete" -#: ../revisor/base.py:944 +#: ../revisor/base.py:950 #, python-format msgid "Total size of all packages (archivesize): %s %s" msgstr "Tamaño total de todos los paquetes (tamaño de archivo): %s %s" -#: ../revisor/base.py:945 +#: ../revisor/base.py:951 #, python-format msgid "Total size of all packages, (installedsize): %s %s" msgstr "Tamaño total de todos los paquetes, (tamaño instalados): %s %s " -#: ../revisor/base.py:946 +#: ../revisor/base.py:952 #, python-format msgid "Total size of all packages, (packagesize): %s %s" msgstr "Tamaño total de todos los paquetes, (tamaño de paquete): %s %s" -#: ../revisor/base.py:981 +#: ../revisor/base.py:987 #, python-format msgid "Report of the %d most space consuming packages" msgstr "Reporte de los %d paquetes que ocupan más espacio" #. Link the localPkg() result into the build tree -#: ../revisor/base.py:1068 -#: ../revisor/base.py:1748 +#: ../revisor/base.py:1074 +#: ../revisor/base.py:1754 msgid "Linking in binary packages" msgstr "Enlazando en paquetes binarios" -#: ../revisor/base.py:1081 +#: ../revisor/base.py:1087 msgid "Linking in source packages" msgstr "Enlazando en paquetes fuente" -#: ../revisor/base.py:1093 +#: ../revisor/base.py:1099 msgid "Linking in debuginfo packages" msgstr "Enlazando en paquetes de debuginfo" -#: ../revisor/base.py:1105 +#: ../revisor/base.py:1111 msgid "Creating Repository Information" msgstr "Creando Información de Repositorio" -#: ../revisor/base.py:1118 +#: ../revisor/base.py:1124 msgid "Source Repo Information" msgstr "Información de Repo Fuente" -#: ../revisor/base.py:1131 +#: ../revisor/base.py:1137 msgid "Debuginfo Repo Information" msgstr "Información de Debug del Repositorio" #. FIXME: Optionally recompose installer images -#: ../revisor/base.py:1146 +#: ../revisor/base.py:1152 msgid "Building Installation Images" msgstr "Construyendo Imágenes de Instalación" -#: ../revisor/base.py:1163 +#: ../revisor/base.py:1169 msgid "Using already existing installer images" msgstr "Usando imagen de instalador ya existentes" -#: ../revisor/base.py:1177 +#: ../revisor/base.py:1183 msgid "Linking in release notes" msgstr "Enlazando en notas de lanzamiento" -#: ../revisor/base.py:1189 +#: ../revisor/base.py:1195 #, python-format msgid "Copying updates.img from %s to %s" msgstr "Copiando updates.img de %s a %s" -#: ../revisor/base.py:1198 +#: ../revisor/base.py:1204 #: ../revisor/pungi.py:412 #, python-format msgid "copy_dir '%s' not accessible" msgstr "copy_dir '%s' no accesible" -#: ../revisor/base.py:1209 +#: ../revisor/base.py:1215 #, python-format msgid "Size of the installation tree is %s MB" msgstr "El tamaño del árbol de instalación es %s MB" @@ -1620,25 +1620,25 @@ msgstr "El tamaño del árbol de instalación es %s MB" #. That makes our lives difficult, hihi #. So, make sure that if we're on el_linux, the repository gets #. bind mounted and configured appropriately -#: ../revisor/base.py:1259 +#: ../revisor/base.py:1265 msgid "Running pkgorder" msgstr "Ejecutando pkgorder" -#: ../revisor/base.py:1320 +#: ../revisor/base.py:1326 #, python-format msgid "Running with grouplist: %r" msgstr "Ejecutando con grouplist: %r" -#: ../revisor/base.py:1323 +#: ../revisor/base.py:1329 #, python-format msgid "Running with packagelist: %r" msgstr "Ejecutando con packagelist: %r" -#: ../revisor/base.py:1330 +#: ../revisor/base.py:1336 msgid "Appending group core and base" msgstr "Añadiendo grupo core y base" -#: ../revisor/base.py:1342 +#: ../revisor/base.py:1348 #, python-format msgid "Appending default group %s" msgstr "Agregando grupo predeterminado %s" @@ -1646,7 +1646,7 @@ msgstr "Agregando grupo predeterminado %s" #. Do not do this because the installer still has all the groups available #. if group not in groupList: #. continue -#: ../revisor/base.py:1364 +#: ../revisor/base.py:1370 #, python-format msgid "Appending non-default group %s" msgstr "Agregando grupo no predeterminado %s" @@ -1654,43 +1654,43 @@ msgstr "Agregando grupo no predeterminado %s" #. Do not do this because the installer still has all the groups available #. if group not in groupList: #. continue -#: ../revisor/base.py:1374 +#: ../revisor/base.py:1380 #, python-format msgid "Appending non-default support group %s" msgstr "Agregando grupo de soporte no predeterminado %s" -#: ../revisor/base.py:1440 +#: ../revisor/base.py:1446 #, python-format msgid "Not running package ordering, using file %s instead" msgstr "No ejecutando ordenación de paquete, usando archivo %s en su lugar" -#: ../revisor/base.py:1442 +#: ../revisor/base.py:1448 msgid "Not running package ordering" msgstr "No ejecutando ordenamiento de paquete" -#: ../revisor/base.py:1474 +#: ../revisor/base.py:1480 msgid "^Install using kickstart" msgstr "^Instalar usando kickstart" #. Split Tree -#: ../revisor/base.py:1497 +#: ../revisor/base.py:1503 #, python-format msgid "Splitting Build Tree (%s)" msgstr "Dividiendo Árbol de Construcción (%s)" #. Split repo -#: ../revisor/base.py:1503 +#: ../revisor/base.py:1509 #, python-format msgid "Splitting Repository (%s)" msgstr "Dividiendo Repositorio (%s)" -#: ../revisor/base.py:1517 +#: ../revisor/base.py:1523 #: ../revisor/modgui/build_media.py:261 #, python-format msgid "Creating %s ISO Image #%d" msgstr "Creando %s Imagen ISO #%d" -#: ../revisor/base.py:1522 +#: ../revisor/base.py:1528 #: ../revisor/modgui/build_media.py:265 #, python-format msgid "Creating %s ISO Image" @@ -1698,50 +1698,50 @@ msgstr "Creando %s Imagen ISO" #. For all images but source images; implant the md5 into the ISO for the media check #. FIXME: Well, it seems we don't deal with source images here. -#: ../revisor/base.py:1536 +#: ../revisor/base.py:1542 msgid "Implanting MD5 into ISO Images" msgstr "Implantando MD5 en las Imágenes ISO" #. mediatype = built_image["mediatype"] #. if not mediatype == 'source': -#: ../revisor/base.py:1544 +#: ../revisor/base.py:1550 #, python-format msgid "Implanting md5 into ISO Image: %s" msgstr "Implantando md5 en la Imágen ISO: %s" -#: ../revisor/base.py:1550 +#: ../revisor/base.py:1556 msgid "Cannot implant ISO md5sum" msgstr "No se puede implantar md5sum a ISO" #. Do some SHA1SUMMONING -#: ../revisor/base.py:1558 +#: ../revisor/base.py:1564 msgid "Creating SHA1SUMs for Images" msgstr "Creando SHA1SUMs para Imagenes" -#: ../revisor/base.py:1574 +#: ../revisor/base.py:1580 msgid "Creating Rescue ISO Image" msgstr "Creando Imagen ISO de Rescate" -#: ../revisor/base.py:1581 +#: ../revisor/base.py:1587 msgid "Creating USB Key Installer" msgstr "Creando Instalador Clave de USB" -#: ../revisor/base.py:1638 -#: ../revisor/base.py:1661 -#: ../revisor/base.py:1684 +#: ../revisor/base.py:1644 +#: ../revisor/base.py:1667 +#: ../revisor/base.py:1690 #, python-format msgid "Copying %s to %s (%d files)" msgstr "Copipando %s a %s (%d archivos)" -#: ../revisor/base.py:1642 -#: ../revisor/base.py:1665 -#: ../revisor/base.py:1688 +#: ../revisor/base.py:1648 +#: ../revisor/base.py:1671 +#: ../revisor/base.py:1694 #, python-format msgid "Moving %s to %s (%d files)" msgstr "Moviendo %s a %s (%d archivos)" -#: ../revisor/base.py:1645 -#: ../revisor/base.py:1668 +#: ../revisor/base.py:1651 +#: ../revisor/base.py:1674 #, python-format msgid "" "Moving of the source tree failed (trying copy):\n" @@ -1752,8 +1752,8 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1648 -#: ../revisor/base.py:1671 +#: ../revisor/base.py:1654 +#: ../revisor/base.py:1677 #, python-format msgid "" "Copying of the source tree failed:\n" @@ -1764,7 +1764,7 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1691 +#: ../revisor/base.py:1697 #, python-format msgid "" "Moving of the installation tree failed (trying copy):\n" @@ -1775,7 +1775,7 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1694 +#: ../revisor/base.py:1700 #, python-format msgid "" "Copying of the installation tree failed:\n" @@ -1786,39 +1786,39 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1703 +#: ../revisor/base.py:1709 msgid "Creating ext3 filesystem" msgstr "Creando sistema de archivos ext3" -#: ../revisor/base.py:1710 +#: ../revisor/base.py:1716 msgid "Configuring System" msgstr "Configurando el Sistema" -#: ../revisor/base.py:1759 +#: ../revisor/base.py:1765 msgid "Linking in Source packages" msgstr "Enlazando en paquetes Fuente" -#: ../revisor/base.py:1787 +#: ../revisor/base.py:1793 #, python-format msgid "Setting rundir to %s" msgstr "Configurando rundir a %s" -#: ../revisor/base.py:1793 +#: ../revisor/base.py:1799 #, python-format msgid "Directory %s could not be created. Aborting" msgstr "El directorio %s no pudo ser creado. Abortando" -#: ../revisor/base.py:1795 +#: ../revisor/base.py:1801 #, python-format msgid "Running command: %s" msgstr "Comando de ejecución: %s" -#: ../revisor/base.py:1796 +#: ../revisor/base.py:1802 #, python-format msgid "Extra information: %s %s %s" msgstr "Información extra: %s %s %s" -#: ../revisor/base.py:1824 +#: ../revisor/base.py:1830 #, python-format msgid "Got an error from %s (return code %s)" msgstr "Se obtuvo error de %s (código devuelto %s)" @@ -2175,6 +2175,11 @@ msgstr "Poniendo self.cfg.payload_livemedia a %s (desde tamaño total de RPMs in msgid "Setting self.cfg.payload_livemedia to %s (from 'part /' command in kickstart, as per the respin mode)" msgstr "Poniendo self.cfg.payload_livemedia a %s (desde el comando 'part /' en kickstart, como para modo de respin)" +#: ../revisor/image.py:221 +#, python-format +msgid "Filesystem type set to: %s" +msgstr "Tipo de sistema de archivos definido en: %s" + #. # #. # Runtime Options #. #

1 0

Changes to 'F-11'
by Jeroen van Meeuwen 19 Jun '09

19 Jun '09

New branch 'F-11' available with the following commits:

1 0

4 commits - configure.ac unity/conf unity/Makefile.am
by Jeroen van Meeuwen 19 Jun '09

19 Jun '09

configure.ac | 2 +- unity/Makefile.am | 2 ++ unity/conf/conf.d/fedora-11-everything.cfg | 3 +++ unity/conf/conf.d/fedora-11-single-cd.cfg | 2 ++ 4 files changed, 8 insertions(+), 1 deletion(-) New commits: commit 6cd00408333b22999d0d4e56ce84d7529aed1346 Merge: b5fe806... 775d634... Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Fri Jun 19 16:51:22 2009 +0200 Merge branch 'master' of ssh://git.fedorahosted.org/git/revisor commit b5fe80657112cf9272e024b6adc4a31f3e0a8dc3 Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Fri Jun 19 16:49:59 2009 +0200 Add everything and single-cd files diff --git a/unity/Makefile.am b/unity/Makefile.am index b0ecb16..31882c5 100644 --- a/unity/Makefile.am +++ b/unity/Makefile.am @@ -12,6 +12,8 @@ etcconf_DATA = \ revisorconfdir = $(sysconfdir)/revisor-unity/conf.d/ revisorconf_DATA = \ + conf/conf.d/fedora-11-everything.cfg \ + conf/conf.d/fedora-11-single-cd.cfg \ conf/conf.d/revisor-f11-i386-respin.conf \ conf/conf.d/revisor-f11-ppc64-respin.conf \ conf/conf.d/revisor-f11-ppc-respin.conf \ commit 485be2378190b978b3ea58912793835e79ab00cf Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Fri Jun 19 16:48:51 2009 +0200 Add everything spin and single-cd files diff --git a/unity/conf/conf.d/fedora-11-everything.cfg b/unity/conf/conf.d/fedora-11-everything.cfg new file mode 100644 index 0000000..92bb857 --- /dev/null +++ b/unity/conf/conf.d/fedora-11-everything.cfg @@ -0,0 +1,3 @@ +%packages +* +%end diff --git a/unity/conf/conf.d/fedora-11-single-cd.cfg b/unity/conf/conf.d/fedora-11-single-cd.cfg new file mode 100644 index 0000000..d609a87 --- /dev/null +++ b/unity/conf/conf.d/fedora-11-single-cd.cfg @@ -0,0 +1,2 @@ +%packages +%end commit ecef56b9e49e5ff9b779ef388298c19c8079db52 Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Fri Jun 19 16:48:22 2009 +0200 Bump version diff --git a/configure.ac b/configure.ac index 9eb8096..47f45dd 100644 --- a/configure.ac +++ b/configure.ac @@ -1,4 +1,4 @@ -AC_INIT([revisor], 2.1.5) +AC_INIT([revisor], 2.1.6) AC_SUBST([RELEASE], 1) AC_CONFIG_SRCDIR(revisor/__init__.py.in)

1 0

po/pl.po
by Transifex System User 18 Jun '09

18 Jun '09

po/pl.po | 175 ++++++++++++++++++++++++++++++++------------------------------- 1 file changed, 90 insertions(+), 85 deletions(-) New commits: commit 775d634205d877c1412c042181e61aace7a6c136 Author: raven <raven(a)fedoraproject.org> Date: Thu Jun 18 20:03:53 2009 +0000 Sending translation for Polish diff --git a/po/pl.po b/po/pl.po index 82435ae..0d48daa 100644 --- a/po/pl.po +++ b/po/pl.po @@ -6,8 +6,8 @@ msgid "" msgstr "" "Project-Id-Version: pl\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2009-04-26 13:34+0200\n" -"PO-Revision-Date: 2009-04-26 13:36+0200\n" +"POT-Creation-Date: 2009-06-18 22:00+0200\n" +"PO-Revision-Date: 2009-06-18 22:03+0200\n" "Last-Translator: Piotr Drąg <piotrdrag(a)gmail.com>\n" "Language-Team: Polish <pl(a)li.org>\n" "MIME-Version: 1.0\n" @@ -1395,23 +1395,23 @@ msgstr "Rozpoczynanie paska postępu dla " msgid "Apparently we have not yet entered the Build Media stage" msgstr "Najwyraźniej nie przeszliśmy jeszcze do etapu budowania nośnika" -#: ../revisor/base.py:504 ../revisor/misc.py:375 +#: ../revisor/base.py:504 ../revisor/misc.py:378 #, python-format msgid "Checking dependencies for %s.%s" msgstr "Sprawdzanie zależności %s.%s" #. pbar.cur_task += 1.0 -#: ../revisor/base.py:526 ../revisor/misc.py:401 +#: ../revisor/base.py:526 ../revisor/misc.py:404 #, python-format msgid "Unresolvable dependency %s %s %s in %s.%s" msgstr "Nie można rozwiązać zależności %s %s %s w %s.%s" -#: ../revisor/base.py:533 ../revisor/misc.py:409 +#: ../revisor/base.py:533 ../revisor/misc.py:412 #, python-format msgid "Added %s-%s:%s-%s.%s for %s-%s:%s-%s.%s (requiring %s %s %s)" msgstr "Dodano %s-%s:%s-%s.%s dla %s-%s:%s-%s.%s (wymaga %s %s %s)" -#: ../revisor/base.py:536 ../revisor/misc.py:242 +#: ../revisor/base.py:536 ../revisor/misc.py:246 msgid "Checking dependencies - allowing conflicts within the package set" msgstr "Sprawdzanie zależności - pozwalanie na konflikty w zestawie pakietów" @@ -1530,131 +1530,131 @@ msgstr "Pobieranie pakietów źródłowych" msgid "Downloading Packages" msgstr "Pobieranie pakietów" -#: ../revisor/base.py:787 +#: ../revisor/base.py:793 #, python-format msgid "Overriding auto package selection with user package selection for %s..." msgstr "" "Zastępowanie automatycznego wyboru pakietów pakietami wybranymi przez " "użytkownika dla %s..." -#: ../revisor/base.py:800 +#: ../revisor/base.py:806 #, python-format msgid "Adding required package %s-%s:%s-%s.%s" msgstr "Dodawanie wymaganego pakietu %s-%s:%s-%s.%s" #. This list has already been resolved -#: ../revisor/base.py:803 +#: ../revisor/base.py:809 #, python-format msgid "%s. This is a required package." msgstr "%s. Ten pakiet jest wymagany." -#: ../revisor/base.py:815 +#: ../revisor/base.py:821 #, python-format msgid "Adding suggested package %s-%s:%s-%s.%s" msgstr "Dodawanie sugerowanego pakietu %s-%s:%s-%s.%s" -#: ../revisor/base.py:826 +#: ../revisor/base.py:832 #, python-format msgid "Adding all-arch package %s-%s:%s-%s.%s" msgstr "Dodawanie pakietu dla wszystkich architektur %s-%s:%s-%s.%s" -#: ../revisor/base.py:863 ../revisor/base.py:889 +#: ../revisor/base.py:869 ../revisor/base.py:895 msgid "Did not succeed in adding in all required packages" msgstr "Dodanie wszystkich wymaganych pakietów nie powiodło się" -#: ../revisor/base.py:897 +#: ../revisor/base.py:903 msgid "Populating statistics" msgstr "Tworzenie statystyk" -#: ../revisor/base.py:913 +#: ../revisor/base.py:919 #, python-format msgid "Package %s-%s:%s-%s.%s does not seem to have a archivesize header" msgstr "" "Wydaje się, że pakiet %s-%s:%s-%s.%s nie posiada nagłówka rozmiaru archiwum" -#: ../revisor/base.py:921 +#: ../revisor/base.py:927 #, python-format msgid "Package %s-%s:%s-%s.%s does not seem to have a installedsize header" msgstr "" "Wydaje się, że pakiet %s-%s:%s-%s.%s nie posiada nagłówka rozmiaru po " "zainstalowaniu" -#: ../revisor/base.py:929 +#: ../revisor/base.py:935 #, python-format msgid "Package %s-%s:%s-%s.%s does not seem to have a packagesize header" msgstr "" "Wydaje się, że pakiet %s-%s:%s-%s.%s nie posiada nagłówka rozmiaru pakietu" -#: ../revisor/base.py:944 +#: ../revisor/base.py:950 #, python-format msgid "Total size of all packages (archivesize): %s %s" msgstr "Całkowity rozmiar wszystkich pakietów (rozmiar archiwum): %s %s" -#: ../revisor/base.py:945 +#: ../revisor/base.py:951 #, python-format msgid "Total size of all packages, (installedsize): %s %s" msgstr "" "Całkowity rozmiar wszystkich pakietów (rozmiar po zainstalowaniu): %s %s" -#: ../revisor/base.py:946 +#: ../revisor/base.py:952 #, python-format msgid "Total size of all packages, (packagesize): %s %s" msgstr "Całkowity rozmiar wszystkich pakietów (rozmiar pakietu): %s %s" -#: ../revisor/base.py:981 +#: ../revisor/base.py:987 #, python-format msgid "Report of the %d most space consuming packages" msgstr "Zgłoś %d pakietów zajmujących najwięcej miejsca" #. Link the localPkg() result into the build tree -#: ../revisor/base.py:1068 ../revisor/base.py:1748 +#: ../revisor/base.py:1074 ../revisor/base.py:1754 msgid "Linking in binary packages" msgstr "Dowiązywanie pakietów binarnych" -#: ../revisor/base.py:1081 +#: ../revisor/base.py:1087 msgid "Linking in source packages" msgstr "Dowiązywanie pakietów źródłowych" -#: ../revisor/base.py:1093 +#: ../revisor/base.py:1099 msgid "Linking in debuginfo packages" msgstr "Dowiązywanie pakietów debuginfo" -#: ../revisor/base.py:1105 +#: ../revisor/base.py:1111 msgid "Creating Repository Information" msgstr "Tworzenie informacji o repozytoriach" -#: ../revisor/base.py:1118 +#: ../revisor/base.py:1124 msgid "Source Repo Information" msgstr "Informacje o repozytorium źródłowym" -#: ../revisor/base.py:1131 +#: ../revisor/base.py:1137 msgid "Debuginfo Repo Information" msgstr "Informacje o repozytorium debuginfo" #. FIXME: Optionally recompose installer images -#: ../revisor/base.py:1146 +#: ../revisor/base.py:1152 msgid "Building Installation Images" msgstr "Budowanie obrazów instalacyjnych" -#: ../revisor/base.py:1163 +#: ../revisor/base.py:1169 msgid "Using already existing installer images" msgstr "Używanie już istniejących obrazów instalatora" -#: ../revisor/base.py:1177 +#: ../revisor/base.py:1183 msgid "Linking in release notes" msgstr "Dowiązywanie informacji o wydaniu" -#: ../revisor/base.py:1189 +#: ../revisor/base.py:1195 #, python-format msgid "Copying updates.img from %s to %s" msgstr "Kopiowanie updates.img z %s do %s" -#: ../revisor/base.py:1198 ../revisor/pungi.py:412 +#: ../revisor/base.py:1204 ../revisor/pungi.py:412 #, python-format msgid "copy_dir '%s' not accessible" msgstr "Nie można uzyskać dostępu do copy_dir \"%s\"" -#: ../revisor/base.py:1209 +#: ../revisor/base.py:1215 #, python-format msgid "Size of the installation tree is %s MB" msgstr "Rozmiar drzewa instalacyjnego wynosi %s MB" @@ -1663,25 +1663,25 @@ msgstr "Rozmiar drzewa instalacyjnego wynosi %s MB" #. That makes our lives difficult, hihi #. So, make sure that if we're on el_linux, the repository gets #. bind mounted and configured appropriately -#: ../revisor/base.py:1259 +#: ../revisor/base.py:1265 msgid "Running pkgorder" msgstr "Wykonywanie pkgorder" -#: ../revisor/base.py:1320 +#: ../revisor/base.py:1326 #, python-format msgid "Running with grouplist: %r" msgstr "Uruchamianie z grouplist: %r" -#: ../revisor/base.py:1323 +#: ../revisor/base.py:1329 #, python-format msgid "Running with packagelist: %r" msgstr "Uruchamianie z packagelist: %r" -#: ../revisor/base.py:1330 +#: ../revisor/base.py:1336 msgid "Appending group core and base" msgstr "Dołączanie grup core i base" -#: ../revisor/base.py:1342 +#: ../revisor/base.py:1348 #, python-format msgid "Appending default group %s" msgstr "Dołączanie domyślnej grupy %s" @@ -1689,7 +1689,7 @@ msgstr "Dołączanie domyślnej grupy %s" #. Do not do this because the installer still has all the groups available #. if group not in groupList: #. continue -#: ../revisor/base.py:1364 +#: ../revisor/base.py:1370 #, python-format msgid "Appending non-default group %s" msgstr "Dołączanie nie domyślnej grupy %s" @@ -1697,89 +1697,89 @@ msgstr "Dołączanie nie domyślnej grupy %s" #. Do not do this because the installer still has all the groups available #. if group not in groupList: #. continue -#: ../revisor/base.py:1374 +#: ../revisor/base.py:1380 #, python-format msgid "Appending non-default support group %s" msgstr "Dołączanie nie domyślnych grup obsługi %s" -#: ../revisor/base.py:1440 +#: ../revisor/base.py:1446 #, python-format msgid "Not running package ordering, using file %s instead" msgstr "" "Porządkowanie kolejności pakietów nie zostanie wykonane, używanie zamiast " "tego pliku %s" -#: ../revisor/base.py:1442 +#: ../revisor/base.py:1448 msgid "Not running package ordering" msgstr "Porządkowanie kolejności pakietów nie zostanie wykonane" -#: ../revisor/base.py:1474 +#: ../revisor/base.py:1480 msgid "^Install using kickstart" msgstr "^Zainstaluj używając kickstart" #. Split Tree -#: ../revisor/base.py:1497 +#: ../revisor/base.py:1503 #, python-format msgid "Splitting Build Tree (%s)" msgstr "Rozdzielanie drzewa budowania (%s)" #. Split repo -#: ../revisor/base.py:1503 +#: ../revisor/base.py:1509 #, python-format msgid "Splitting Repository (%s)" msgstr "Rozdzielanie repozytorium (%s)" -#: ../revisor/base.py:1517 ../revisor/modgui/build_media.py:261 +#: ../revisor/base.py:1523 ../revisor/modgui/build_media.py:261 #, python-format msgid "Creating %s ISO Image #%d" msgstr "Tworzenie %s obrazu ISO #%d" -#: ../revisor/base.py:1522 ../revisor/modgui/build_media.py:265 +#: ../revisor/base.py:1528 ../revisor/modgui/build_media.py:265 #, python-format msgid "Creating %s ISO Image" msgstr "Tworzenie %s obrazu ISO" #. For all images but source images; implant the md5 into the ISO for the media check #. FIXME: Well, it seems we don't deal with source images here. -#: ../revisor/base.py:1536 +#: ../revisor/base.py:1542 msgid "Implanting MD5 into ISO Images" msgstr "Wprowadzanie MD5 do obrazów ISO" #. mediatype = built_image["mediatype"] #. if not mediatype == 'source': -#: ../revisor/base.py:1544 +#: ../revisor/base.py:1550 #, python-format msgid "Implanting md5 into ISO Image: %s" msgstr "Wprowadzanie MD5 do obrazu ISO: %s" -#: ../revisor/base.py:1550 +#: ../revisor/base.py:1556 msgid "Cannot implant ISO md5sum" msgstr "Nie można wprowadzić md5sum ISO" #. Do some SHA1SUMMONING -#: ../revisor/base.py:1558 +#: ../revisor/base.py:1564 msgid "Creating SHA1SUMs for Images" msgstr "Tworzenie plików SHA1SUM dla obrazów" -#: ../revisor/base.py:1574 +#: ../revisor/base.py:1580 msgid "Creating Rescue ISO Image" msgstr "Tworzenie ratunkowego obrazu ISO" -#: ../revisor/base.py:1581 +#: ../revisor/base.py:1587 msgid "Creating USB Key Installer" msgstr "Tworzenie instalatora dysku USB" -#: ../revisor/base.py:1638 ../revisor/base.py:1661 ../revisor/base.py:1684 +#: ../revisor/base.py:1644 ../revisor/base.py:1667 ../revisor/base.py:1690 #, python-format msgid "Copying %s to %s (%d files)" msgstr "Kopiowanie %s do %s (%d plików)" -#: ../revisor/base.py:1642 ../revisor/base.py:1665 ../revisor/base.py:1688 +#: ../revisor/base.py:1648 ../revisor/base.py:1671 ../revisor/base.py:1694 #, python-format msgid "Moving %s to %s (%d files)" msgstr "Przenoszenie %s do %s (%d plików)" -#: ../revisor/base.py:1645 ../revisor/base.py:1668 +#: ../revisor/base.py:1651 ../revisor/base.py:1674 #, python-format msgid "" "Moving of the source tree failed (trying copy):\n" @@ -1790,7 +1790,7 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1648 ../revisor/base.py:1671 +#: ../revisor/base.py:1654 ../revisor/base.py:1677 #, python-format msgid "" "Copying of the source tree failed:\n" @@ -1801,7 +1801,7 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1691 +#: ../revisor/base.py:1697 #, python-format msgid "" "Moving of the installation tree failed (trying copy):\n" @@ -1812,7 +1812,7 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1694 +#: ../revisor/base.py:1700 #, python-format msgid "" "Copying of the installation tree failed:\n" @@ -1823,39 +1823,39 @@ msgstr "" "\n" "%s" -#: ../revisor/base.py:1703 +#: ../revisor/base.py:1709 msgid "Creating ext3 filesystem" msgstr "Tworzenie systemu plików ext3" -#: ../revisor/base.py:1710 +#: ../revisor/base.py:1716 msgid "Configuring System" msgstr "Konfigurowanie systemu" -#: ../revisor/base.py:1759 +#: ../revisor/base.py:1765 msgid "Linking in Source packages" msgstr "Dowiązywanie pakietów źródłowych" -#: ../revisor/base.py:1787 +#: ../revisor/base.py:1793 #, python-format msgid "Setting rundir to %s" msgstr "Ustawianie rundir na %s" -#: ../revisor/base.py:1793 +#: ../revisor/base.py:1799 #, python-format msgid "Directory %s could not be created. Aborting" msgstr "Nie można utworzyć folderu %s. Przerywanie" -#: ../revisor/base.py:1795 +#: ../revisor/base.py:1801 #, python-format msgid "Running command: %s" msgstr "Wykonywanie polecenia: %s" -#: ../revisor/base.py:1796 +#: ../revisor/base.py:1802 #, python-format msgid "Extra information: %s %s %s" msgstr "Dodatkowe informacje: %s %s %s" -#: ../revisor/base.py:1824 +#: ../revisor/base.py:1830 #, python-format msgid "Got an error from %s (return code %s)" msgstr "Otrzymano błąd z %s (kod zwrotny %s)" @@ -2263,6 +2263,11 @@ msgstr "" "Ustawianie self.cfg.payload_livemedia na %s (z polecenia \"part /\" w " "kickstart, tak jak w trybie ponownego komponowania)" +#: ../revisor/image.py:221 +#, python-format +msgid "Filesystem type set to: %s" +msgstr "Typ systemu plików został ustawiony na: %s" + #. # #. # Runtime Options #. # @@ -2732,7 +2737,7 @@ msgstr "Z pakietów: dodawanie %s-%s:%s-%s.%s do transakcji" msgid "Could not find package '%s', searching..." msgstr "Nie można znaleźć pakietu \"%s\", wyszukiwanie..." -#: ../revisor/kickstart.py:556 ../revisor/misc.py:206 +#: ../revisor/kickstart.py:556 ../revisor/misc.py:210 #, python-format msgid "Found packages matching '%s': %s" msgstr "Znaleziono pakiety pasujące do \"%s\": %s" @@ -2751,12 +2756,12 @@ msgstr "" "Znaleziono więcej niż jeden pakiet dla %s-%s-%s.%s - wszystkie zostaną " "dodane do transakcji" -#: ../revisor/kickstart.py:580 ../revisor/misc.py:220 +#: ../revisor/kickstart.py:580 ../revisor/misc.py:224 #, python-format msgid "Could not find package %s-%s-%s.%s" msgstr "Nie można znaleźć pakietu %s-%s-%s.%s" -#: ../revisor/kickstart.py:583 ../revisor/misc.py:223 +#: ../revisor/kickstart.py:583 ../revisor/misc.py:227 #, python-format msgid "From Packages (exact string %s-%s-%s.%s), selecting %s-%s-%s.%s" msgstr "Z pakietów: (dokładny łańcuch %s-%s-%s.%s), wybieranie %s-%s-%s.%s" @@ -2823,17 +2828,17 @@ msgstr "Nie można znaleźć odpowiedniego serwera lustrzanego." msgid "Errors were encountered while downloading packages: %s" msgstr "Podczas pobierania pakietów wystąpiły błędy: %s" -#: ../revisor/misc.py:193 ../revisor/misc.py:231 +#: ../revisor/misc.py:197 ../revisor/misc.py:235 #, python-format msgid "Resolved %s" msgstr "Rozwiązano %s" -#: ../revisor/misc.py:218 +#: ../revisor/misc.py:222 #, python-format msgid "More then one package found for %s-%s-%s.%s" msgstr "Znaleziono więcej niż jeden pakiet dla %s-%s-%s.%s" -#: ../revisor/misc.py:234 +#: ../revisor/misc.py:238 #, python-format msgid "" "Looking to resolve package %s to a Provides, but we still can't find it." @@ -2841,66 +2846,66 @@ msgstr "" "Próbowanie rozwiązania pakietu %s do dostarczanych, ale wciąż nie można go " "znaleźć." -#: ../revisor/misc.py:246 +#: ../revisor/misc.py:250 #, python-format msgid "Inclusive dependency resolving starts at %s" msgstr "Dołączanie podczas rozwiązywania zależności zaczyna się o %s" -#: ../revisor/misc.py:267 +#: ../revisor/misc.py:271 #, python-format msgid "Inclusive dependency resolving ends at %s" msgstr "Dołączanie podczas rozwiązywania zależności kończy się o %s" -#: ../revisor/misc.py:316 +#: ../revisor/misc.py:319 #, python-format msgid "Cannot find a source rpm for %s" msgstr "Nie można znaleźć źródłowego pakietu RPM dla %s" -#: ../revisor/misc.py:339 +#: ../revisor/misc.py:342 #, python-format msgid "Disabling %s repository" msgstr "Wyłączanie repozytorium %s" -#: ../revisor/misc.py:354 +#: ../revisor/misc.py:357 #, python-format msgid "No such repository: %s" msgstr "Brak repozytorium: %s" -#: ../revisor/misc.py:356 +#: ../revisor/misc.py:359 #, python-format msgid "Enabling %s repository" msgstr "Włączanie repozytorium %s" -#: ../revisor/misc.py:555 ../revisor/misc.py:560 +#: ../revisor/misc.py:558 ../revisor/misc.py:563 #, python-format msgid "Creating destination directory: %s" msgstr "Tworzenie folderu docelowego: %s" -#: ../revisor/misc.py:558 +#: ../revisor/misc.py:561 #, python-format msgid "Removing destination directory: %s" msgstr "Usuwanie folderu docelowego: %s" -#: ../revisor/misc.py:574 +#: ../revisor/misc.py:577 #, python-format msgid "Package hard link failed: %s: %s" msgstr "Twarde dowiązanie pakietów nie powiodło się: %s: %s" -#: ../revisor/misc.py:579 +#: ../revisor/misc.py:582 #, python-format msgid "Copying: %s to %s" msgstr "Kopiowanie: %s do %s" -#: ../revisor/misc.py:582 +#: ../revisor/misc.py:585 #, python-format msgid "Symlinking: %s to %s" msgstr "Dowiązywanie symboliczne: %s do %s" -#: ../revisor/misc.py:585 +#: ../revisor/misc.py:588 msgid "Package symlink succeeded" msgstr "Dowiązanie symboliczne pakietów powiodło się" -#: ../revisor/misc.py:587 ../revisor/misc.py:594 +#: ../revisor/misc.py:590 ../revisor/misc.py:597 #, python-format msgid "Package link failed, trying copy: %s: %s" msgstr "Dowiązanie pakietów nie powiodło się, próbowanie skopiowania: %s: %s"

1 0

8 commits - conf/conf.d doc/Reference_Manual doc/Revisor_Documentation revisor/image.py revisor/pungi.py unity/conf
by Jeroen van Meeuwen 18 Jun '09

18 Jun '09

conf/conf.d/fedora-11-gold.cfg | 23 doc/Reference_Manual/en-US/Appendix.xml | 475 + doc/Reference_Manual/en-US/Author_Group.xml | 16 doc/Reference_Manual/en-US/Book_Info.xml | 37 doc/Reference_Manual/en-US/Preface.xml | 56 doc/Reference_Manual/en-US/Reference_Manual.ent | 5 doc/Reference_Manual/en-US/Reference_Manual.xml | 27 doc/Reference_Manual/en-US/Revision_History.xml | 26 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Compose_Process_Details.xml | 431 + doc/Reference_Manual/en-US/Revisor_Reference_Manual-Configuration.xml | 280 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Development.xml | 220 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Features.xml | 175 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Frequently_Asked_Questions.xml | 54 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Installation.xml | 104 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Introduction.xml | 71 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Plugins.xml | 131 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Testing.xml | 173 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tips_and_Tricks.xml | 47 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tweaking_The_Build_Process.xml | 40 doc/Reference_Manual/en-US/Revisor_Reference_Manual-Using_Kickstart.xml | 118 doc/Reference_Manual/en-US/images/icon.svg | 3936 ++++++++++ doc/Revisor_Documentation/en-US/Appendix.xml | 475 - doc/Revisor_Documentation/en-US/Author_Group.xml | 16 doc/Revisor_Documentation/en-US/Book_Info.xml | 34 doc/Revisor_Documentation/en-US/Preface.xml | 56 doc/Revisor_Documentation/en-US/Revision_History.xml | 26 doc/Revisor_Documentation/en-US/Revisor_Documentation-Compose_Process_Details.xml | 431 - doc/Revisor_Documentation/en-US/Revisor_Documentation-Configuration.xml | 280 doc/Revisor_Documentation/en-US/Revisor_Documentation-Development.xml | 220 doc/Revisor_Documentation/en-US/Revisor_Documentation-Features.xml | 175 doc/Revisor_Documentation/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml | 54 doc/Revisor_Documentation/en-US/Revisor_Documentation-Installation.xml | 104 doc/Revisor_Documentation/en-US/Revisor_Documentation-Introduction.xml | 71 doc/Revisor_Documentation/en-US/Revisor_Documentation-Plugins.xml | 131 doc/Revisor_Documentation/en-US/Revisor_Documentation-Testing.xml | 173 doc/Revisor_Documentation/en-US/Revisor_Documentation-Tips_and_Tricks.xml | 47 doc/Revisor_Documentation/en-US/Revisor_Documentation-Tweaking_The_Build_Process.xml | 40 doc/Revisor_Documentation/en-US/Revisor_Documentation-Using_Kickstart.xml | 118 doc/Revisor_Documentation/en-US/Revisor_Documentation.ent | 5 doc/Revisor_Documentation/en-US/Revisor_Documentation.xml | 27 doc/Revisor_Documentation/en-US/images/icon.svg | 3936 ---------- revisor/image.py | 2 revisor/pungi.py | 4 unity/conf/f11-install-single-cd.conf | 3 44 files changed, 6445 insertions(+), 6428 deletions(-) New commits: commit 2189919f4e2ffe0da241317ca3d234118e003181 Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Thu Jun 18 16:05:22 2009 +0200 Fix references to files diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Compose_Process_Details.xml b/doc/Reference_Manual/en-US/Reference_Manual-Compose_Process_Details.xml deleted file mode 100644 index 6b12e6c..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Compose_Process_Details.xml +++ /dev/null @@ -1,431 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Compose_Process_Details"> - <title>Compose Process Details</title> - <para> - This chapter lists the details of the compose process as well as dives deep into the features of Revisor. - </para> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Overview"> - <title>Overview</title> - <titleabbrev id="Compose_Process_Details-Overview">Overview</titleabbrev> - <para> - Of course, the compose process for installation media is a little different then the compose process for live media. - </para> - <para> - When composing, Revisor starts out doing the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Revisor initiates and loads plugins, options, and defaults. At this point, Revisor has a so-called <emphasis>ConfigStore</emphasis> that holds all options Revisor knows about. - </para> - </listitem> - <listitem> - <para> - Revisor reads the options from the command-line. - </para> - </listitem> - <listitem> - <para> - Revisor reads the configuration file specified with the <code>--config</code> command-line parameter, or uses it's builtin default, <filename>/etc/revisor/revisor.conf</filename>. - </para> - </listitem> - <listitem> - <para> - Revisor reads the global <code>[revisor]</code> section for all settings available in it's <emphasis>ConfigStore</emphasis> and sets those configured in the global section. Remember that if an option is not available in the <emphasis>ConfigStore</emphasis> but is configured in the global configuration section, it is ignored. - </para> - </listitem> - <listitem> - <para> - If a model is specified in the configuration file's global section <code>[revisor]</code>, Revisor will set that model to be used and loads it. - </para> - </listitem> - <listitem> - <para> - If a model has been specified on the command-line, with option <code>--model</code>, Revisor loads that model. - </para> - </listitem> - <listitem> - <para> - When loading the model, Revisor again iterates over all the settings that are in the <emphasis>ConfigStore</emphasis>, checks if the setting has been configured in the model section, and adjusts the setting in the <emphasis>ConfigStore</emphasis> if necessary. Again remember that if the <emphasis>ConfigStore</emphasis> does not know about one or the other option already, that setting is ignored. - </para> - </listitem> - <listitem> - <para> - Now that the defaults and configuration file settings have been applied to the <emphasis>ConfigStore</emphasis>, it is time for Revisor to look at the options specified on the command-line to see if you wanted to override anything. - </para> - </listitem> - <listitem> - <para> - While loading each configuration setting available in the global <code>[revisor]</code>, model-specific sections and/or command-line, Revisor checks every settings against a function that is specifically written to check such setting. For example, the label of an ISO cannot be longer then 32 characters. - </para> - </listitem> - <listitem> - <para> - Especially in CLI mode, these settings build up the task list for Revisor. If there's nothing to do, Revisor will throw an error explaining what's missing. If there's things to do that cannot be done in one run, Revisor will throw an error explaining that. - </para> - </listitem> - <listitem> - <para> - In Graphical User Interface mode however, if the settings loaded so far are all OK, the GUI will start. Since you can still adjust a few settings from within the GUI, the settings loaded so far will be the defaults for configuration settings that have a dialog for you to adjust them with, throughout the rest of the process. - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Installation_Media"> - <title>Installation Media</title> - <para> - As we've explained before, composing installation media is a little different then composing live media. That's not just because installation media should start an installation procedure and live media should show you a nice, shiny, fully-functional Desktop. - </para> - <para> - For one, installation media allows split media. This means that Revisor can span the payload of the product over multiple ISO images or multiple discs, if you will. When composing installation media, Revisor basically does the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Of course, Revisor goes through the loading of configuration options mentioned in the <xref linkend="Revisor_Reference_Manual-Compose_Process_Details-Overview" endterm="Compose_Process_Details-Overview" />. - </para> - </listitem> - <listitem> - <para> - When you're done specifying options in the GUI, or when Revisor thinks it can go ahead using the options specified in CLI mode, it takes the list of packages selected from either the GUI or the kickstart <code>%packages</code> manifest. - </para> - <para> - Not getting too deep into details here, yet, because some of these things are routines shared with other composing modes, but here's a few additional considerations Revisor makes when doing the package selection. - </para> - <para> - <itemizedlist> - <listitem> - <para> - Normally, a kickstart <code>%packages</code> manifest only allows you to select package <emphasis>names</emphasis>. With Revisor though, you can select exact package <emphasis>NEVRA</emphasis> to select a certain version or architecture for the package that you want. Additionally, if a package is not available, Revisor searches the <emphasis>Provides</emphasis> of the available packages. - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Live_Media"> - <title>Live Media</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode"> - <title>Respin Mode</title> - <para> - Revisor has a respin mode that in some aspects differs from the regular routines. It is intended to reflect behaviour of tools in use by the Fedora Project Release Engineering team as closely as possible. - </para> - <para> - Re-Spin mode only affects installation media products. - </para> - <para> - In Re-Spin mode, the way the RPM payload is determined from kickstart differs from Revisor's normal procedures. See <xref linkend="Revisor_Reference_Manual-Using_Kickstart" /> for more details on using a kickstart package manifest. - </para> - <para> - A kickstart file's so-called <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-package_manifest" /> usually looks like: - </para> - <para> - <screen>%packages -@group1 -@group2 --nodefaults -@group3 --optional -package1 -package2 --package3 -%end</screen> - </para> - <para> - Which tells us the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Include all mandatory and default packages from group1 - </para> - </listitem> - <listitem> - <para> - Include all mandatory packages from group2 - </para> - </listitem> - <listitem> - <para> - Include all mandatory, default and optional packages from group3 - </para> - </listitem> - <listitem> - <para> - Include package1, and package2 - </para> - </listitem> - <listitem> - <para> - Exclude package3 - </para> - </listitem> - </itemizedlist> - </para> - <para> - Depending on how you use this instructions or information, there is a slight difference in the package set that ends up on the media you compose. - </para> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode-Selecting_Groups"> - <title>Selecting Groups</title> - <para> - Selecting groups has the following logic: When you load a repository you may also load the groups file (often referred to as 'comps' or 'comps.xml'). This comps file is an XML file with categories, groups (per category), and per group: - </para> - <para> - <itemizedlist> - <listitem> - <para> - a list of mandatory packages. If you select or include the group, these packages come with it. - </para> - </listitem> - <listitem> - <para> - a list of default packages. If you select or include the group, these packages will come with it as a default. If you only want the mandatory, minimum set of packages for this group, in a kickstart package manifest append <code>--nodefaults</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Deselect all packages</emphasis>. - </para> - </listitem> - <listitem> - <para> - a list of optional packages. If you select a group you have not yet selected these packages. To select the optional packages of a group, in a kickstart package manifest append <code>--optional</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Select all optional packages</emphasis>. - </para> - </listitem> - <listitem> - <para> - a list of conditionals. If you select this group, these conditionals are thrown into the package sack and transaction information and include or exclude other packages. Suppose you select the '@nl-support' or “Dutch Support” group from the Languages or Localization category, you would end up with support for the Dutch language in all applications that have that kind of support. - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode-Select_Matching_Packages"> - <title>Select Matching Packages</title> - <para> - This is the logic Revisor applies when running in Re-Spin mode (on the CLI, specify <code>--respin</code>). It imitates the behavior pungi has, and thus enables you to copy that behavior. Note that <code>--respin</code> has other implications as well. - </para> - <para> - First of all, it iterates the groups in the kickstart package manifest. For each group, it appends the names of the mandatory packages to a list, and depending on the additional parameters specified with that group (<code>--nodefaults</code> or <code>--optional</code>), appends the names of the other packages in that group as well. - </para> - <para> - Then it iterates over the package names in the package manifest. These package names are appended to the same list of package names too. This includes package 'names' with some sort of wildcard (?, or *). - </para> - <para> - Then it iterates over all the excluded packages, appending each of those to the YUM configuration exclude list. - </para> - <para> - Now that Revisor has a very simple, flat list of package names, it uses YUM's internal matching logic 5 to get what packages in the repositories matched exactly (by name), matched (by wildcard) and did not match at all. Revisor then selects the exact matches and matches, adding them to the transaction. - </para> - </section> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving"> - <title>Dependency Resolving</title> - <indexterm> - <primary>Dependency Resolving</primary> - </indexterm> - <para> - Dependency resolving is the area where some of the efficiency Revisor can gain for you comes from. While of course there is specific reasons to do things one way, or the other, most people I speak to about Revisor, it is not very clear why, or what Revisor does in this area. First of all, there's two ways of resolving dependencies: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title>Inclusive Dependency Resolving</title> - <indexterm> - <primary>Dependency Resolving</primary> - <secondary>Inclusive</secondary> - </indexterm> - <para> - Iterate all packages in the transaction and list their requirements, then for each of those requirements, find all packages that provide a matching capability, add those packages to the transaction, and don't forget to add the requirements those packages have themselves, back into the pile of (unmet) requirements. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>Exclusive Dependency Resolving</title> - <indexterm> - <primary>Dependency Resolving</primary> - <secondary>Inclusive</secondary> - </indexterm> - <para> - Iterate all the packages and for each of the requirements found, find the best package that meets the requirement. This is also YUMs default behavior. Anaconda uses YUM during the installation, and this is the behaviour of YUM used during the installation. - </para> - </formalpara> - </listitem> - </orderedlist> - </para> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive"> - <title>Inclusive Dependency Resolving</title> - <para> - Hypothetically, you could describe inclusive dependency as follows: - </para> - <para> - <screen>final_packages = [] -more_to_do = True -while more_to_do: -more_to_do = False -for package in packages: - if package in final_packages: - continue - - dependencies = find_package_dependencies() - for dependency in dependencies: - pulled_in_package = pull_in_dependency() - if pulled_in_package not in final_packages: - packages.append(pulled_in_package) - more_to_do = True</screen> - </para> - <para> - So, what does this mean? Basically, it means that if there is a requirement for a capability, all packages providing that capability are being pulled in. Now imagine package 'foo' requires capability 'web-client'. There's a number of packages providing that capability, right? So you get Firefox, lynx, elinks, konqueror, safari, Netscape, Internet Explorer, emacs, for free! All of those pull in their own dependencies also, of course. - </para> - <note> - <para> - If you catch this before it catches you, you can prevent the packages from being pulled in during dependency resolving by not making the package available in the <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-Package_Sack" /> in the first place, using the <literal>-firefox</literal> syntax in the kickstart package manifest, and setting <literal>kickstart_uses_pkgsack_excludes</literal> to 1. - </para> - </note> - <note> - <para> - You may have thought of it; pulling in packages this way may give you a package set (or <emphasis>RPM payload</emphasis>) that has conflicting packages. Imagine package <application>foo</application> requiring capability <application>bar</application>, which is provided by two packages that conflict with one another (either on explicit <literal>Conflicts:</literal> RPM header or file level). Both will be pulled in, hence disabling you to install everything (<literal>'*'</literal> or -previously- <literal>@Everything</literal> in the kickstart package manifest). - </para> - </note> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Makes_Sense"> - <title>When This Makes Sense</title> - <para> - If you are composing a large distribution of which 3 million users in even so many different situations having so many different expectations and desires, you will want this behaviour, since you won't be able to determine which one of the packages for each capability someone in that group wants, and which one may not want. Or, in case of upgrades, what the system needs. Shipping them all on the same media is the best solution in these cases. - </para> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Does_Not_Make_Sense"> - <title>When This Does Not Make Sense</title> - <para> - <itemizedlist> - <listitem> - <para> - When creating installation media to be installed unattended, or to be used in conjunction with deployment strategies - </para> - </listitem> - <listitem> - <para> - When creating installation media to be upgrading PCs you have controlled from the beginning, such as in a company - </para> - </listitem> - <listitem> - <para> - Installation for a small group of users or systems - </para> - </listitem> - <listitem> - <para> - When creating minimal installation media, or media with a minimal RPM payload. - </para> - </listitem> - <listitem> - <para> - When creating installation media that is to be used with installing "Everything" in the RPM payload. - </para> - </listitem> - </itemizedlist> - </para> - </section> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Exclusive"> - <title>Exclusive Dependency Resolving</title> - <para> - Exclusive dependency resolving is what YUM does when you execute a <application>yum install</application>. Unless you've specified one of the packages satisfying any of the dependencies in the transaction, YUM is going to look up the best match for you. This results in the installation of only one package providing the requirement(s) of other packages, rather then all packages providing said requirement being installed. - </para> - <para> - As an example, imagine you install a package foo which requires capability web-client. Using exclusive dependency resolving, YUM would select one package providing the web-client capability whereas inclusive dependency resolving would include all packages providing the web-client capability. - </para> - <para> - During the installation procedure, one of the major features of installation media, anaconda is going to use YUM dependency resolving to satisfy all the dependencies. - </para> - <note> - <title>Installation Procedure !== Upgrade Procedure</title> - <para> - Note that an installation procedure is not the same as an upgrade procedure. With an installation procedure for example, you have control over the partitioning layout whereas with an upgrade procedure, you have none. More importantly, during an upgrade procedure, the (already installed) system has an existing package set which needs to be updated/upgraded and thus could possibly introduce dependency resolving problems, because of third party packages installed on the system, or because the media used to upgrade the system with does not contain the software packages needed to complete the upgrade RPM transaction. - </para> - </note> - </section> - - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Copying_Arbitrary_Files_Onto_The_Media"> - <title>Copying Arbitrary Files Onto the Media</title> - <para> - With <literal>--copy-dir</literal>, you can specify a path Revisor should copy onto the media. - </para> - <formalpara> - <title>Installation Media</title> - <para> - In the case of installation media, the path specified with <literal>--copy-dir</literal> will be copied recursively to the <filename>files/</filename> sub-directory at the root of the ISO image (or the first ISO image if you compose split media). - </para> - </formalpara> - <para> - A few use-case examples: - </para> - <para> - <itemizedlist> - <listitem> - <para> - If one kickstart profile is not enough for you to deploy the product onto your systems, create a directory that holds multiple kickstart files and specify the path to that directory using <literal>--copy-dir</literal>. The kickstart files now end up available to the installation procedures as <filename>cdrom:/files/*.ks</filename>, and can thus be used by specifying them on the kernel cmdline (<code>ks=cdrom:/files/profile1.ks</code>), or, when used in combination with <literal>--isolinux-cfg</literal> from the <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin" endterm="Isolinux_Plugin" />, can be added as an option in the isolinux menu. - </para> - </listitem> - <listitem> - <para> - If you have files or scripts that need to be copied onto, or run on, the installed system before it attempts to reboot and operate normally, you can use <literal>--copy-dir</literal> to make these files and scripts available during the installation and copy or execute them from either <code>%pre</code> or <code>%post</code> scripts. - </para> - </listitem> - </itemizedlist> - </para> - <formalpara> - <title>Live Media</title> - <para> - In the case of live media, the path specified with <literal>--copy-dir</literal> will be copied recursively onto the root directory (<filename>/</filename>) of the live media filesystem (which is probably loop-mounted onto <filename>/var/tmp/revisor/</filename>). - </para> - </formalpara> - <para> - If, for example, you want to copy a home directory onto the live media, and the home directory you want to copy is at <filename>/home/user1/</filename> on the composing system, you copy this directory so that the root of that new directory has a sub-directory <filename>home/</filename> which in turn contains a sub-directory <filename>user1/</filename>: - </para> - <para> - <screen>$ <userinput>mkdir -p /tmp/something/home/</userinput> -$ <userinput>cp -a /home/user1 /tmp/something/home/.</userinput> -$ <userinput>revisor [options] --copy-dir /tmp/something/</userinput></screen> - </para> - </section> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Cleaning_Up"> - <title>Cleaning Up</title> - <para> - Revisor tends to clean up after itself by default. If a product compose succeeds, you (probably) don't need to change this default behaviour. However, by default, Revisor tends to leave the YUM cache directories untouched. This is to prevent you from having to download all the packages a second, third or more times when you run another compose. - </para> - <para> - To change this default behaviour, Revisor has an option <literal>--clean-up</literal>. The default value for this option is <literal>1</literal>, meaning Revisor will clean up it's temporary, compose-specific files, but no files that could be re-used. Specifying <literal>--clean-up=0</literal> will cause Revisor to leave everything behind and not clean anything up at all. This is most ideal for troubleshooting purposes, where one needs to examine the temporary, compose-specific files and see what went wrong. To clean up everything however, because for example you might be low on disk-space, use <literal>--clean-up=2</literal>. Revisor will then also clean up the files that could be re-used. - </para> - - <section id="Revisor_Reference_Manual-Compose_Process_Details-Cleaning_Up-Exception-to-the-Rule"> - <title>Exception to the Rule</title> - <para> - There's one exception to the rule of cleaning up. <filename>/var/tmp/revisor/</filename>, or put more accurately, the path specified as the <code>installroot</code> in the YUM configuration file configured with the model used to compose the product, will not be cleaned up afterwards. When composing live media, this directory may still be in use as a mount-point for the live media filesystem. Removing this directory recursively in these cases would not make sense. - </para> - </section> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Configuration.xml b/doc/Reference_Manual/en-US/Reference_Manual-Configuration.xml deleted file mode 100644 index 647706f..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Configuration.xml +++ /dev/null @@ -1,280 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Configuration"> - <title>Configuration</title> - <para> - Revisor configuration can be performed using <xref linkend="Revisor_Reference_Manual-Configuration-Files" />, or through <xref linkend="Revisor_Reference_Manual-Configuration-Command-line_Options" />. - </para> - - <section id="Revisor_Reference_Manual-Configuration-Files"> - <title>Configuration Files</title> - <para> - Revisor uses configuration files for a large part of it's operations. These files mostly reside in <filename>/etc/revisor/</filename>. There is two types of files Revisor uses: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title>Revisor Configuration Files</title> - <para> - Revisor configuration files, such as <filename>/etc/revisor/revisor.conf</filename>, contain information and settings unique to Revisor. A Revisor configuration file is where you specify default options, and include information on different products you want to compose. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>YUM Configuration Files</title> - <para> - YUM configuration files, such as the files in <filename>/etc/revisor/conf.d/</filename>, contain configuration for YUM. To be more precise, Revisor doesn't even handle the files (it let's YUM do so). The files in <filename>/etc/revisor/conf.d/</filename> practically contain the same information as <filename>/etc/yum.conf</filename> combined with the files in <filename>/etc/yum.repos.d/</filename> (but not exactly the same content!). - </para> - </formalpara> - </listitem> - </orderedlist> - </para> - - <section id="Revisor_Reference_Manual-Configuration-Files-_etc_revisor_revisor.conf"> - <title><filename>/etc/revisor/revisor.conf</filename></title> - <para> - The default Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. This configuration file contains two sections: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title><literal>[revisor]</literal></title> - <para> - The global section. Options specified in this section apply to all the models defined in this configuration file. - </para> - </formalpara> - <para> - See also: <xref linkend="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration" /> - </para> - </listitem> - <listitem> - <formalpara> - <title><literal>[<replaceable>model</replaceable>]</literal></title> - <para> - Model configuration. One section per <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-model" />. - </para> - </formalpara> - <para> - See also: <xref linkend="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration" /> - </para> - </listitem> - </orderedlist> - </para> - <para> - Model sections basically define a single product. Amongst other things, the distribution name, release version, architecture for the product to be composed and what YUM configuration file to use, are (often) defined on a per-model basis. There is a large number of settings available for models, and they are all related to how the product is going to look like. The product name, the location of the RPM payload for installation media, the ISO label, the YUM configuration file to use, are all model settings. - </para> - <para> - Using models, you can reproduce the outcome of the compose process, a <emphasis>product</emphasis>, simply by not changing the model configuration anymore. If you want something different, you can just add another model section, and name it differently. - </para> - <para> - To see what models are available with the Revisor standard package, use: - </para> - <para> - <screen>$ <userinput>revisor --list-models</userinput></screen> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Files-_etc_revisor_conf.d_"> - <title><filename>/etc/revisor/conf.d/</filename></title> - <para> - The default YUM configuration files used by Revisor. In a model configuration section, the <literal>main =</literal> setting points to one of the YUM configuration files in <filename>/etc/revisor/conf.d/</filename> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Files-Updates"> - <title>Updates to Configuration Files</title> - <para> - The Revisor packages are not allowed to overwrite files in <filename>/etc/</filename>, and they should thus not do so. If an update to Revisor is installed on your system, files with the extension <literal>.rpmnew</literal> may be created --if you had changed anything in the file before applying the update. Since this world isn't perfect, configuration errors may exist in the configuration files shipped with Revisor. Please pay close attention to updates to these configuration files by examining the <literal>.rpmnew</literal> files. - </para> - <para> - You can use any file location (not just <filename>/etc/revisor/</filename>) for your own custom configuration. - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Files-Changing_Configuration_Files"> - <title>Changing Configuration Files</title> - <para> - If you are creating your own models off of the ones that ship with Revisor itself, please consider using an alternative configuration file (a file other then <filename>/etc/revisor/revisor.conf</filename>, or copy the original file for safekeeping. This way, you can always return to a working, sample configuration file and test whether it is Revisor causing errors, or configuration mistakes. - </para> - </section> - - </section> - - <section id="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration"> - <title>Global and Model Configuration</title> - <para> - The default Revisor configuration file, <filename>/etc/revisor/revisor.conf</filename> consists of multiple sections (the file is in .INI format). One is the <literal>[revisor]</literal> global section, where you specify configuration options that apply to each other section or <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-model" />. - </para> - <para> - The options specified in the global and model configuration sections apply to the Revisor compose in the following order: - </para> - <para> - <orderedlist> - <listitem> - <para> - The options from the global section are read, tested and set. - </para> - </listitem> - <listitem> - <para> - The options from a model section are read, tested and set, regardless of whether the global section had caused the setting to be set to a certain value already. - </para> - </listitem> - </orderedlist> - </para> - <para> - For example, if you know all the models in a configuration file are optical live media products, the configuration sections could look like the following: - </para> - <para> - <screen>[revisor] -# Optical live media for all models -media_live_optical = 1 - -[model1] -main = /etc/revisor/conf.d/revisor-model1.conf -description = The model1 product -architecture = i386 -# This is already configured in the global section of -# this configuration file and can thus be removed. -#media_live_optical = 1</screen> - </para> - <note> - <title>When Running the GUI</title> - <para> - Note that when running Revisor in Graphical User Interface mode, you can still change a lot of the settings supplied by Revisor through the configuration files loaded. When you are running Revisor in GUI mode, the configuration files supply the defaults. - </para> - </note> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories"> - <title>YUM Repository Configuration</title> - <para> - The files in <filename>/etc/revisor/conf.d/</filename> are YUM configuration files. Revisor directs YUM to use these files during the compose process, and does not handle these files itself. This chapter lists a few tips and tricks. - </para> - <para> - Because these files are YUM Configuration files, you can configure anything that YUM supports. See <application>man yum.conf</application> for more details. - </para> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-releasever_and_basearch"> - <title>$releasever and $basearch</title> - <para> - When configuring a repository URL, make sure you do not use <replaceable>$releasever</replaceable> or <replaceable>$basearch</replaceable> variables. Since Revisor allows cross-composing distributions between different versions of the operating system, as well as different architectures, these variables need to be expanded to the value intended. - </para> - <para> - See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_a_Local_Mirror"> - <title>Using a Local Mirror</title> - <para> - If you have a local mirror of Fedora, you can use the <literal>baseurl</literal> configuration directive in each repository configuration section to tell YUM to use the local mirror. - </para> - <para> - Optionally, you can also disable the <literal>mirrorlist</literal>, preferably by outcommenting it, so that YUM will only use the local mirror. - </para> - <para> - The default <literal>baseurl</literal> uses <literal>http://download.fedoraproject.org/</literal>. This location may or may not be suitable for you. If you have a local mirror, you might want to change this setting here, or add your mirror to Fedora Project's Mirrorlist. - </para> - <note> - <title>Adding your local mirror to the Mirrorlist</title> - <para> - You can add your local mirror to the Mirrorlist, so that the Fedora Project mirrorlist redirects you to your local mirror. Additionally, systems in your local network(s) will be redirected to the local mirror. The local mirror does not have to be a public mirror in order to do so. See <ulink url="http://admin.fedoraproject.org/mirrormanager/" /> for more details. - </para> - </note> - <para> - Set each <literal>baseurl</literal> to the location of the repository on the local mirror. - </para> - <para> - See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_Local_Files"> - <title>Using Local Files</title> - <para> - If you have the repositories on your local filesystem, configure a <literal>baseurl</literal> of <filename>file://<replaceable>/path/to/repository/</replaceable></filename>. - </para> - <note> - <title>Make sure to supply the correct path</title> - <para> - Make sure to supply the correct path to the repository. <filename>file://</filename> is the "<emphasis>protocol</emphasis>" for the location, and the location is <filename><replaceable>/path/to/repository/</replaceable></filename>. Put together, you have <emphasis>three</emphasis> slashes. - </para> - </note> - <para> - See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_a_DVD"> - <title>Using a DVD</title> - <para> - A DVD does not contain enough packages to rebuild the installer images. If you are using a DVD and you want to rebuild the installer images, you will need to have a network connection and a mirror you can reach. - </para> - <para> - There is a list of required packages, but since the packages change per release and may change in the middle of the release cycle as well, we cannot hand you a list that just works. - </para> - <para> - See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Adding_Third_Party_Repositories"> - <title>Adding Third Party Repositories</title> - <para> - When adding a third party repository, make sure you add the correct release version as well as architecture to the Revisor YUM configuration file. Verify the location for the <literal>baseurl</literal> and/or <literal>mirrorlist</literal> you configure manually or through YUM. Make sure you expand any <literal>$releasever</literal>, <literal>$basearch</literal> and <literal>$arch</literal> variables. - </para> - <para> - See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Creating_Your_Own_Repository"> - <title>Creating Your Own Repository</title> - <para> - Creating your own repository is relatively simple. You take a directory, dump some RPM packages in it, and run <application>createrepo</application>. See <literal>man createrepo</literal> for more information. - </para> - <para> - People often wonder how Revisor handles comps.xml group files. - </para> - <para> - When you create your own repository, follow the directions in <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Adding_Third_Party_Repositories" /> to add the repository configuration to Revisor's YUM configuration, since your own repository is a third party repository as well. - </para> - <para> - See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting"> - <title>Testing & Troubleshooting the YUM Configuration</title> - <para> - Before you use the (modified) configuration file, take it for a test run. - </para> - </section> - - </section> - - <section id="Revisor_Reference_Manual-Configuration-Configuring_A_Proxy"> - <title>Configuring A Proxy Server</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Configuration-Command-line_Options"> - <title>Command-line Options</title> - <para> - With the command-line options available, you can configure options that either override what is in the configuration file or have simply not been configured using the configuration file. With the default configuration files that come with the <application>revisor-cli</application> package for example, no media products have been pre-configured in the default section. In the <application>revisor-unity</application> package however, some default configuration has been applied so that Fedora Unity Re-Spins actually create CD, DVD and Rescue ISO images as well as the Installation Tree and include the sources. - </para> - <para> - Only some configuration options have CLI parameters. Use <application>revisor --help</application> to see a complete list of configuration options you can supply on the command line. - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Development.xml b/doc/Reference_Manual/en-US/Reference_Manual-Development.xml deleted file mode 100644 index 9df83c1..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Development.xml +++ /dev/null @@ -1,220 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Development"> - <title>Development</title> - <para> - This chapter sheds some light on development of Revisor, such as different branches and maintenance policies, versioning schemas, etcetera. - </para> - <para> - This part of the documentation relies on whether you have <application>sudo</application> set up properly. If you have not, you're on your own. - </para> - - <section id="Revisor_Reference_Manual-Development-Running_Revisor_from_Source"> - <title>Running Revisor from Source</title> - <para> - The latest code in GIT can be built into a RPM you can install but one of the advantages of having the complete source tree is that you can run it directly from that source tree so that when you pull in the next updates you do not have to rebuild the RPM. Note that we do not bump the version number for every little change we make, and as such the RPM built does not allow you to use <literal>rpm -Uvh</literal> or <literal>rpm -Uvh --oldpackage</literal>. Of course, Revisor's Makefiles also allow <application>make install</application>, but that leaves a number of unmanaged files on your computer you would have to track down manually in order to remove Revisor completely. - </para> - <warning> - <title>Cannot have Revisor RPMs installed</title> - <para> - When running revisor from within the source tree, you cannot have any of the Revisor packages installed. Having Revisor RPM packages installed regardless will mess up the GIT repository or source tree. - </para> - </warning> - <para> - To run Revisor from within the source tree, checkout the master branch, and run the <filename>./switchhere</filename> script: - </para> - <para> - <screen>$ <userinput>./switchhere</userinput></screen> - </para> - <para> - The <filename>./switchhere</filename> script does the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Symlink <filename>/etc/revisor/</filename> to <filename><replaceable>$PWD</replaceable>/conf/</filename> so that <filename>/etc/revisor/revisor.conf</filename>, the primary configuration file, and <filename>/etc/revisor/conf.d/</filename>, the configuration directory, are valid (the symlink causes the actual file and directory to be found in <filename><replaceable>$PWD</replaceable>/conf/</filename>) - </para> - </listitem> - <listitem> - <para> - Create the <filename>/usr/share/revisor/</filename> directory so that a couple of symlinks can be created from within that directory: - </para> - </listitem> - <listitem> - <para> - In Revisor 2.1.0 (development version in branch master), this includes: - </para> - <para> - <itemizedlist> - <listitem> - <para> - <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/revisor/modgui/glade/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/revisor/modgui/glade/pixmaps/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - <listitem> - <para> - In Revisor 2.0.5 (branch F-7, F-8 or EL-5), this includes: - </para> - <para> - <itemizedlist> - <listitem> - <para> - <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/glade/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/glade/pixmaps/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - <listitem> - <para> - In Revisor 2.1.0, also create symlinks from within the appropriate <filename>/usr/share/man/man<replaceable>$x</replaceable>/</filename> directories to the source for these man pages in <filename><replaceable>$PWD</replaceable>/doc/</filename>. - </para> - </listitem> - </itemizedlist> - </para> - <para> - From this moment on, you should be able to run: - </para> - <para> - <screen>$ <userinput>./revisor.py</userinput></screen> - </para> - <note> - <title>Root privileges required</title> - <para> - Note that revisor needs root privileges to run, and that you'll need to sudo or su-c to gain those. Use here whatever you find the most convenient; Revisor though should have a nice error message when run without those privileges. - </para> - </note> - - <section id="Revisor_Reference_Manual-Development-Running_Revisor_from_Source-Required_Packages"> - <title>Installing the Required Packages</title> - <para> - To be able to run Revisor from within the source tree, you'll need to install the required packages for each component, of course. - </para> - <para> - To get a current list of those packages, use: - </para> - <para> - <screen>$ <userinput>rpmquery --specfile --qf="%{REQUIRES}\n" revisor.spec | sort | uniq | xargs -n 1 repoquery --requires --alldeps --resolve</userinput></screen> - </para> - </section> - - </section> - - <section id="Revisor_Reference_Manual-Development-Building_Revisor_Packages"> - <title>Building Revisor Packages</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Development-Tickets"> - <title>Tickets</title> - <para> - bugzilla, trac - </para> - </section> - - <section id="Revisor_Reference_Manual-Development-Adding_A_New_Spin"> - <title>Adding a new spin or remix</title> - <para> - <orderedlist> - <listitem> - <para> - Add the appropriate models in the appropriate configuration file for Revisor. - </para> - </listitem> - <listitem> - <para> - Add the appropriate configuration file to the appropriate automake Makefile - </para> - </listitem> - <listitem> - <para> - Run autoreconf && ./configure && make rpm to verify the rpm building - </para> - </listitem> - <listitem> - <para> - Create the model's YUM configuration files with the following repositories: - </para> - <para> - <itemizedlist> - <listitem> - <para> - fedora, enabled, pointing to Everything - </para> - </listitem> - <listitem> - <para> - fedora-source, disabled, pointing to Everything - </para> - </listitem> - <listitem> - <para> - fedora-updates, enabled, pointing to the updates repository - </para> - </listitem> - <listitem> - <para> - fedora-updates-source, disabled, pointing to the updates repository - </para> - </listitem> - <listitem> - <para> - anaconda-updates, enabled, pointing to the anaconda updates repository - </para> - </listitem> - <listitem> - <para> - anaconda-updates-source, disabled, pointing to the ananconda updates repository - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - </orderedlist> - </para> - </section> - - <section id="Revisor_Reference_Manual-Development-Versioning_Schema"> - <title>Versioning Schema</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Development-Release_Procedure"> - <title>Release Procedure</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Features.xml b/doc/Reference_Manual/en-US/Reference_Manual-Features.xml deleted file mode 100644 index 6321641..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Features.xml +++ /dev/null @@ -1,175 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Features"> - <title>Features</title> - <para> - Revisor allows you to build and customize your own Remix, Re-Spin, Spin or even your own distribution, based on Fedora and derivative distributions such as Red Hat Enterprise Linux and CentOS. - </para> - <para> - Revisor builds installation media, live media, installation trees, cobbler distro's and profiles, virtualization images and more. - </para> - - <section id="Revisor_Reference_Manual-Features-Installation_Media"> - <title>Installation Media</title> - <para> - Installation media is what you use to install a system with. The installation media composed will allow you to go through the installation process, answering a number of questions (either manually or through kickstart), and ends up in a system running the distribution you install. - </para> - <para> - Composing installation media using the Revisor GUI allows you to choose the media (CD, or DVD), the packages to be included on the media (also called <emphasis>RPM payload</emphasis>). - </para> - <para> - Using the command-line interface, Revisor also allows you to choose DVD Duallayer and single- or dual-layer Bluray. - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Installation_Trees"> - <title>Installation Trees</title> - <para> - Installation trees are typically used in environments where a distribution needs to be deployed over multiple systems, or is very volatile. Installation trees are often made accessible through HTTP or FTP protocols, in one place, and do not have as much overhead (in creating .iso files, and burning those to optical media to distribute them). - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Live_Media"> - <title>Live Media</title> - <para> - Live media often is a perfect showcase for an Operating system, Desktop Environment or any other thing you want to show. Also, since Live media is read-only, live media perfectly allows for a kiosk system, a system that may change while it's running, but restores all original settings when rebooted. - </para> - <para> - Live media is also installable. You start out with a system and boot it from live media, then choose to install the live media. This however is inferior to real installation media, but is convenient if you happen to like what you see when running from live media. - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Reproducibility"> - <title>Reproducibility</title> - <para> - Media composed with Revisor is extremely reproducible. Using <literal>kickstart_exact_nevra</literal>, you can even select specific versions of packages to be included on the product. - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Consistency"> - <title>Consistency</title> - <para> - When composing different types of media, such as CDs and DVDs, Revisor composes these discs in one run, making the different media completely consistent. <application>pungi</application> would require you to run twice, once for CDs, and once for DVDs. This is because <application>pungi</application> uses the <literal>part / <replaceable><size></replaceable></literal> kickstart configuration directive to set the maximum size of the media, and has no option to override the size on the command-line, nor to compose a certain set of media (it all depends on the size). - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Flexibility"> - <title>Flexibility</title> - <para> - Over the years, Revisor has been adopted to serve a large number of use-cases, where use-cases stretch from media being composed as efficient as possible, as robust as possible, specific deployment needs and expectations, and to match the Fedora Project Release Engineering tools' behaviour. All this allows you to configure a lot, and thus customize a lot, making Revisor more of a flexible framework. - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Graphical_User_Interface"> - <title>Graphical User Interface</title> - <para> - Revisor has a Graphical User Interface or GUI, in addition to the Command Line Interface or CLI, which makes Revisor more accessible to users then the other tools, which are CLI only. Most people only know of Revisor through the GUI, and may think there is no CLI to Revisor. Only when it comes down to many of the additional features that Revisor has, and that do not fit in a simplified GUI, one gets down with it using the CLI. - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Open_Development_Community"> - <title>Open Development Community</title> - <para> - Revisor has one of those old-fashioned Free and Open Source Software development communities, allowing anyone to make a contribution to Revisor. In fact, Revisor has not bounced a single patch since the project started. Therefor, it improves faster then any of the other compose tools, and is better adaptible to your needs and expectations, because unlike the other utilities, Revisor is not limited to use-cases that apply to Fedora Project Release Engineering. - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Plugin_System"> - <title>Plugin System</title> - <para> - Revisor has a plugin system so that you can easily extend Revisor. This plugin system gives you full control over the Revisor procedures, and hands you off anything Revisor knows about the compose process. There's are multiple plugins available from upstream as well. To give you an example, the ability to replace <filename>isolinux.cfg</filename> after the compose is done, is a plugin. See <xref linkend="Revisor_Reference_Manual-Plugins" /> for more information. - </para> - - <para> - Current plugins included with Revisor include: - </para> - <para> - <itemizedlist> - <listitem> - <para> - <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Cobbler_Plugin" /> - </para> - </listitem> - <listitem> - <para> - <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin" /> - </para> - </listitem> - <listitem> - <para> - <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Rebrand_Plugin" /> - </para> - </listitem> - <listitem> - <para> - <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Reuse_Installer_Images_Plugin" /> - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Extraneous_Debugging"> - <title>Extraneous Debugging</title> - <para> - Revisor has extraneous debugging, which enables you, as well as the supporters and Revisor's developers, to trace down what happens exactly, and where anything might go wrong. - </para> - </section> - - <section id="Revisor_Reference_Manual-Features-Using_YUM_Configuration_Files"> - <title>Using YUM Configuration Files</title> - <para> - Revisor uses YUM configuration files, where everyone else is not. With using YUM configuration files however, the control you have is nearly limitless. With all the features in YUM already, using it's configuration file format and letting YUM itself work with those allows Revisor to do a lot of cool things without doing anything itself: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title>Excluding packages from repositories</title> - <para> - Excluding packages from repositories means a great deal. Not having them exist in the <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-Package_Sack" /> ensures the package will not end up in the product. This may be what you want for maybe just a few, or maybe an awful lot of packages. - </para> - </formalpara> - <para> - Using the alternative configuration file format, kickstart, in use by every other compose tool, and the <literal>repo</literal> configuration directive that is available with kickstart, you can exclude packages using the <literal>--exclude=</literal> parameter to the <literal>repo</literal> configuration directive. However, that parameter does not allow wildcard matches. - </para> - </listitem> - <listitem> - <formalpara> - <title>Including only a certain (set of) package(s)</title> - <para> - Including only a certain package, or certain set of packages is valuable when a lot of packages exist in the repository configured, but you only need one or two. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>Concurrent use of baseurl(s) and the mirrorlist</title> - <para> - Like during normal YUM operations, the baseurl(s) and the mirrorlist configured for a repository are used concurrently. This is not possible with the kickstart configuration directive <literal>repo</literal>, which takes either <literal>--baseurl</literal> or <literal>--mirrorlist</literal>, but not both. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>Repository priorities</title> - <para> - Settings available with YUM are available within Revisor as well, like repository priorities. Using repository priorities, you can have YUM decide to pull a package from the repository with a higher priority (a lower priority number) rather then a repository with a lower priority. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>YUM Plugins</title> - <para> - YUM plugins, such as <application>yum-fastestmirror</application>, <application>yum-fedorakmod</application>, are available, giving you even more control over the behaviour of YUM. - </para> - </formalpara> - </listitem> - </orderedlist> - </para> - </section> -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Frequently_Asked_Questions.xml b/doc/Reference_Manual/en-US/Reference_Manual-Frequently_Asked_Questions.xml deleted file mode 100644 index 7e97e0e..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Frequently_Asked_Questions.xml +++ /dev/null @@ -1,54 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Frequently_Asked_Questions"> - <title>Frequently Asked Questions</title> - <para> - para - </para> - - <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-How_Does_Revisor_Handle_Comps"> - <title>How Does Revisor Handle Comps?</title> - <para> - para - </para> - </formalpara> - - <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-What_Are_Installer_Images"> - <title>What Are Installer Images?</title> - <para> - para - </para> - </formalpara> - - <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Pungi"> - <title>What is the relationship between Revisor and Pungi?</title> - <para> - Where pungi builds a bunch of RPMs into ISO images and installation trees through one single procedure, perfect for Release Engineering on something like the Fedora Project, Revisor does it different entirely. - </para> - </formalpara> - - <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Livecd-tools"> - <title>What is the relationship between Revisor and livecd-tools?</title> - <para> - Revisor depends on livecd-tools for the composing of live media. Creating the filesystem to install the packages to, turning that image file into a SquashFS file, and applying the settings inside the chroot. - </para> - </formalpara> - - <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Why_Rebuild_Installer_Images"> - <title>Why Rebuild Installer Images?</title> - <para> - para - </para> - </formalpara> - - <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-How_do_I_create_an_updates.img"> - <title>How do I create an updates.img?</title> - <para> - para - </para> - </formalpara> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Installation.xml b/doc/Reference_Manual/en-US/Reference_Manual-Installation.xml deleted file mode 100644 index f56855f..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Installation.xml +++ /dev/null @@ -1,104 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Installation"> - <title>Installation</title> - <para> - This chapter contains the installation instructions for Revisor. - </para> - - <section id="Revisor_Reference_Manual-Installation-Packages"> - <title>Packages</title> - <para> - You can install Revisor using RPM packages from the repositories already configured on your system. - </para> - - <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor"> - <title><application>revisor</application></title> - <para> - Shorthand package for the Revisor GUI. - </para> - </formalpara> - - <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor-cli"> - <title><application>revisor-cli</application></title> - <para> - The CLI version of Revisor. This package is always installed, as it contains the Python code for Revisor's core. Installing just this package will give you the command-line version of Revisor, and prevents the graphical dependencies from the <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor-gui" /> package to be installed as well. - </para> - </formalpara> - - <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor-gui"> - <title><application>revisor-gui</application></title> - <para> - The GUI version of Revisor. This is the actual package containing the Graphical User Interface, as opposed to <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor" />. Depends on <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor-cli" />, and thus also installs the command-line version of Revisor. - </para> - </formalpara> - - <section id="Revisor_Reference_Manual-Installation-Packages-YUM-RHEL"> - <title>Red Hat Enterprise Linux 5 or higher</title> - <para> - On Red Hat Enterprise Linux 5 or higher, and derivatives, install the Extra Packages for Enterprise Linux (EPEL) repository. - </para> - <para> - Then, give the following command: - </para> - <para> - <screen># <userinput>yum install revisor</userinput></screen> - </para> - </section> - - <section id="Revisor_Reference_Manual-Installation-Packages-YUM-Fedora"> - <title>Fedora 7 or higher</title> - <para> - On Fedora 7 or higher, and derivatives, no additional repository configuration is required. - </para> - <para> - Give the following command: - </para> - <para> - <screen># <userinput>yum install revisor</userinput></screen> - </para> - <note> - <title>About EOL Releases</title> - <para> - Please bear in mind that Fedora releases that are past the point of End-Of-Life, approximatly 13 months after the initial release, are not supported anymore for use with Revisor. Also, the version of Revisor running on these EOL versions of Fedora are not supported anymore. - </para> - </note> - </section> - - </section> - - <section id="Revisor_Reference_Manual-Installation-The_Latest_And_Greatest"> - <title>The Latest and Greatest</title> - <para> - The latest and greatest is available from GIT, at <ulink url="git://git.fedorahosted.org/revisor" />. To clone this repository, use: - </para> - <para> - <screen>$ <userinput>git clone git://git.fedorahosted.org/revisor/</userinput></screen> - </para> - <para> - Using the GIT clone, you have the several options to start using the latest and greatest: - </para> - <formalpara> - <title>Running directly from the source</title> - <para> - You can run directly from within the source tree. See <xref linkend="Revisor_Reference_Manual-Development-Running_Revisor_from_Source" /> for more information on how to do so. - </para> - </formalpara> - <warning> - <title>Installed packages and running from source</title> - <para> - Do not run Revisor from source while RPM packages have been installed. Files managed by a package will get created, moved and removed when using Revisor's source tree, and updates to the installed RPM packages will destroy these changes. - </para> - </warning> - <formalpara> - <title>Building your own packages</title> - <para> - You can create your own packages, so that you have all the benefits of RPM. See <xref linkend="Revisor_Reference_Manual-Development-Building_Revisor_Packages" /> for more information on how to do so. - </para> - </formalpara> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Introduction.xml b/doc/Reference_Manual/en-US/Reference_Manual-Introduction.xml deleted file mode 100644 index 561b37c..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Introduction.xml +++ /dev/null @@ -1,71 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Introduction"> - <title>Introduction</title> - <para> - Revisor is a community product by Fedora Unity. Amongst other features, it allows the creation of installation media and live media in the easiest possible manner, through a click-and-go GUI. This chapter gives some insight on how and why Revisor was born, and how the product evolved since. - </para> - - <section id="Revisor_Reference_Manual-Introduction-History_Of_Revisor"> - <title>History of Revisor</title> - <para> - Revisor development started in December 2006, during the Fedora 7 development cycle, in which -you might recall- the Fedora Core repository, maintained by Red Hat, and Fedora Extras repository, mostly maintained by the community, were merged into one large repository being maintained by both community members as well as Red Hat employees -which are mostly community members hired by Red Hat -so community altogether. Before then Red Hat employees maintained Fedora Core -as the set of packages upstream for Red Hat's Enterprise product- and the community maintained a repository with additional software; Fedora Extras. Red Hat composed the Fedora distribution every once in a while, but the merge introduced the possibility for packages that were in Fedora Extras to be included in the main distribution, and for the community to also (co-)maintain the (former) Fedora Core packages that originally made up the distribution. - </para> - <para> - In addition to this huge merge of packages, Red Hat employees were also able to release the entire build process to the community, meaning that from the moment the source is committed up and until the release is announced, the entire process is open. Not that is was all behind closed doors or proprietary or anything, the community just couldn't really play with it as much. We now have koji (build system), mash (repository compose from build system products), bodhi (updates release system), livecd-tools (compose tool for live media) and pungi (compose tool for installation media). - </para> - <para> - Composing media was an obscure process up and until the moment these tools exposed the best way to compose (a set of) installation media. Fedora Unity had been building and releasing so-called Re-Spins1 regularly, but they were built using a not-so-very intelligent bash script. Like hundreds if not thousands of other parties that needed to build their own media one way or the other, the entire process was based on the best educated guess of what should happen. Luckily, in the FOSS world an educated guess is often a very good guess, despite the fact that one keeps learning even years after the original engagement. - </para> - <para> - When in December 2006 the compose tools hit a stage in which they were released to the public, Fedora Unity was eager to get these tools and study them and use them for composing their Re-Spins. Up and until then, Re-Spins were composed with the aforementioned bash script that didn't do much but trigger the appropriate commands in a sequence; There wasn't any dependency resolving between the packages included nor did we know exactly how a release was supposed to be composed -it was our educated guess of how it could happen. Although it often led to success, we've had many, many failed Re-Spins as well. With a handful of volunteers, you can imagine the amount of frustration that might give. Fedora Unity was eager to improve their Re-Spin process. - </para> - <para> - So, early February 2007, a number of Fedora Unity members attended “FUDCon 2007” in Boston, and presented a working GUI front-end to livecd-tools and pungi enabling regular users to also re-compose or re-spin the installation media and live media they had been getting from the Fedora Project. Revisor at this point just made it “as easy as possible”. Besides the possibilities of pungi and livecd-tools themselves, the wizard Revisor had apparently was very, very useful to mere mortals. From that point on, things took off. - </para> - <para> - Fedora Unity decided Revisor could accomplish more then just being a front-end to existing compose tools and enable someone to tweak a lot of settings as well. In March 2007, Revisor was rebuild from the ground up in March 2007 to allow a more flexible process, more dependent on the configuration directives it was given and less so on the processes of the existing tools. When in San Diego at the Red Hat Summit (early May 2007), Robert 'Bob' Jensen and Jonathan Steffan gave a presentation on “Customizing Fedora”, the responses were amazing. Since then Revisor has evolved from a front-end to existing tools to the complete compose tool it is today, with lots of configuration options for specific use-cases. - </para> - <para> - For users, Revisor is particularly useful because it has a GUI front-end wizard, which, with the defaults settings, will just succeed in getting a user the media he/she wants. If a user decides he needs little adjustment of the media, the GUI allows for selecting the most common options. If a user decides he needs some less common adjustments, the configuration options gives him very granular control -and as long as the documentation on all the options is sufficient, users will be able to make those less common adjustments. - </para> - <para> - For administrators on the other hand, Revisor is the tool that gives so much granular control over what happens, that it can serve almost every specific use-case. In this aspect, Revisor could potentially replace the compose tools administrators have been developing themselves with a consistent and flexible program flow. - </para> - <para> - This document should enable you to study the process of composing installation and live media, and comprehend the logic Revisor adds to that process. - </para> - </section> - - <section id="Revisor_Reference_Manual-Introduction-The_Installation_Media_Challenge"> - <title>The Installation Media Challenge</title> - <para> - When Fedora Unity first started doing these so-called Re-Spins, the challenge ahead could maybe be explained like this: - </para> - <para> - <emphasis>When a user downloads a Fedora release and installs the distribution, the user will need to download and install a number of updates. The “older” the release becomes, the more updates will be available, and the greater the total download size of these updates the user will need to download on top of the download size of the original release media.</emphasis> - </para> - <para> - “older” is in quotes on purpose, because really for an operating system -or “distribution” if you will- being released every 6 months, “old” is quite a relative concept. The number of updates available however, at any given time during the release cycle, may range from 0 right after the release (which has never happened before), to the total amount of packages installed on the user's system (often over 2000). You can imagine the size of these updates ranging from 0 MB to an astonishing 2GB(!), only 6 months after the initial release. - </para> - <para> - Some of us do not have the bandwidth capacity or enough data transfer quota to download this many extra, rather useless bits. In addition, some of us do not have an Internet connection at all, and thus benefit getting the updates from Re-Spins directly. - </para> - <para> - The use of updates in Re-Spins has several more beneficial side-effects, which we'll explain in more detail later on in this document. Long story short; If for some reason the software used to compose the media (the release) with does not work for your hardware or your specific needs, updated software incorporated in the composed installer images might resolve that problem. - </para> - <para> - This is the original challenge the Fedora Unity team resolved a long time ago, and is at the base of what Revisor does nowadays. - </para> - </section> - - <section id="Revisor_Reference_Manual-Introduction-The_Live_Media_Challenge"> - <title>The Live Media Challenge</title> - <para> - Back in the day Fedora Core 5 was the most recent release, Fedora Unity created so-called live media using Kadischi. In that time, live media could only have a read-only root file system and was not as feature-rich as live media is today. However, just before Revisor came to life, two applications were developed; pungi for creating installation media, and livecd-tools for creating live media. These two applications did their work well; The media composed for a release, including many different custom live media spins were, and still are, created with these tools. Immediately, the Revisor developers set themselves a target to provide a single interface to both of those tools. - </para> - </section> - -</chapter> diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Plugins.xml b/doc/Reference_Manual/en-US/Reference_Manual-Plugins.xml deleted file mode 100644 index 122f25e..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Plugins.xml +++ /dev/null @@ -1,131 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Plugins"> - <title>Plugins</title> - <para> - para - </para> - - <section id="Revisor_Reference_Manual-Plugins-Upstream"> - <title>Upstream Plugins</title> - <para> - Plugins available from upstream, maintained by upstream - </para> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Cobbler_Plugin"> - <title>Cobbler Plugin</title> - <para> - The Cobbler plugin is able to put the product composed into a Cobbler environment, by handing off the built product to the existing Cobbler infrastructure as a <emphasis>distro</emphasis>, and creating a <emphasis>profile</emphasis>. - </para> - <para> - Using this module, one can automatically import the Revisor product into a Cobbler environment, and immediately use the new Cobbler <emphasis>profile</emphasis> to start deploying or automated testing, maybe. - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Composer_Plugin"> - <title>Composer Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Delta_Plugin"> - <title>Delta Plugin</title> - <para> - A small change to a ISO image does not require you to download the complete ISO image if you have a copy of the old ISO image. - </para> - <note> - <title>Only applicable to (...)</title> - <para> - The generation of Delta ISO images is only applicable to situations in which the ISO image does not contain SquashFS images. SquashFS images are smaller, but all SquashFS images are unique. Since the Delta principle is based on similarities, and no two SquashFS images are alike, creating a Delta on two ISO images containing SquashFS images will lead to a Delta pratically the same size as the SquashFS image. For Live Media that compresses the ext3 filesystem image into a SquashFS image, since that SquashFS image is probably over 97% of the size of the ISO image, creating Delta images for compressed Live Media does not make sense. For installation media however, most RPMs would be similar as well as (potentially) the installer images. - </para> - </note> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-GUI_Plugin"> - <title>GUI (Graphical User Interface) Plugin</title> - <para> - Yes, the Graphical User Interface for Revisor is actually a plugin. - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-HUB_Plugin"> - <title>HUB Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin"> - <title>Isolinux Plugin</title> - <titleabbrev id="Isolinux_Plugin">Isolinux Plugin</titleabbrev> - <para> - The isolinux plugin adds the <literal>--isolinux-cfg</literal> command-line option to Revisor. Specify a file here, and the original <filename>isolinux.cfg</filename> that is built as part of the compose process is replaced by the <filename>isolinux.cfg</filename> specified. - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Jigdo_Plugin"> - <title>Jigdo Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Mock_Plugin"> - <title>Mock Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Rebrand_Plugin"> - <title>Rebrand Plugin</title> - <para> - The rebrand plugin hooks in to Revisor at several different stages. The goal of this plugin is to ensure no trademarked packages end up on the media. Trademarked packages may include <application>fedora-logos</application>, <application>redhat-logos</application>, and so forth. - </para> - <para> - The plugin adds a <literal>--rebrand</literal> option, to which you can specify the name of your new product. When rebranding Fedora to Omega for example, specifying <literal>--rebrand Omega</literal> would be sufficient to make sure the product does not have any Fedora trademarks. - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Reuse_Installer_Images_Plugin"> - <title>Reuse Installer Images Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Server_Plugin"> - <title>Server Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-Virtualization_Plugin"> - <title>Virtualization Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Plugins-Upstream-WUI_Plugin"> - <title>WUI (Web-based User Interface) Plugin</title> - <para> - para - </para> - </section> - - </section> - - <section id="Revisor_Reference_Manual-Plugins-Writing_Your_Own"> - <title>Writing Your Own Plugins</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Testing.xml b/doc/Reference_Manual/en-US/Reference_Manual-Testing.xml deleted file mode 100644 index ea4ff00..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Testing.xml +++ /dev/null @@ -1,173 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Testing"> - <title>Testing</title> - <para> - The following test cases describe different types of testing a new Revisor release. - </para> - - <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases"> - <title>Simple Test Cases</title> - <para> - This section has a few simple test cases ensuring configuration shipped with Revisor works as anticipated. - </para> - - <section id="Revisor_Reference_Manual-Testing-Simple_Test_cases-Packages"> - <title>Packages</title> - <para> - Install the <application>revisor-cli</application>: - </para> - <para> - <screen># <userinput>yum --enablerepo=updates-testing install revisor</userinput></screen> - </para> - <para> - Installed are all dependencies for the Revisor CLI interface. Make sure <application>spin-kickstarts</application> is installed, a package for sample kickstarts. - </para> - <para> - Starting Revisor as follows should not show any error messages related to Revisor attempting to start up it's GUI interface: - </para> - <para> - <screen># <userinput>revisor</userinput></screen> - </para> - - <formalpara> - <title>Configuration Files</title> - <para> - The following configuration files should exist: - </para> - </formalpara> - <para> - <itemizedlist> - <listitem> - <para> - <filename>/etc/revisor/revisor.conf</filename> - </para> - </listitem> - </itemizedlist> - </para> - <para> - Each section should have a configuration file listed as <literal>main</literal>. - </para> - <para> - And, of course, every configuration file listed in each section. In this case, the following snippet is easy enough: - </para> - <para> - <screen>$ <userinput>i=0; \ -configfiles="`grep ^main /etc/revisor/revisor.conf | \ - sed -r -e 's/^main.*=\s*(.*)/\1/g'`" - -for configfile in $configfiles; do \ - [ ! -f $file ] && i=1; \ -done; \ -echo $i</userinput></screen> - </para> - <para> - Another way to test the configuration file is to execute: - </para> - <para> - <screen>$ <userinput>revisor --list-models >/dev/null</userinput></screen> - </para> - <para> - If everything is well, since <literal>STDOUT</literal> is redirected to <filename>/dev/null</filename>, you should see no messages at all. - </para> - - </section> - - <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases-Configuration_Files"> - <title>Configuration Files</title> - <para> - The main Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. The file lists a series of models, each having their own YUM configuration file in <filename>/etc/revisor/conf.d/</filename>. - </para> - <formalpara> - <title>Testing</title> - <para> - <itemizedlist> - <listitem> - <para> - For each model in <filename>/etc/revisor/revisor.conf</filename>, the <code>main</code> setting for that model should point to a valid file. - </para> - </listitem> - <listitem> - <para> - Each YUM configuration file should work. To verify, run the following command for each configuration file: - </para> - <para> - <screen>$ yum -c <replaceable>$file</replaceable> list kernel</screen> - </para> - </listitem> - </itemizedlist> - </para> - </formalpara> - <formalpara> - <title>Known Errors</title> - <para> - <itemizedlist> - <listitem> - <para> - Revisor has baseurls in YUM repositories set to <ulink url="http://localrepo" />. This URL will not be retrievable for many people, but allows the developers to quickly change mirrors. - </para> - </listitem> - <listitem> - <para> - Repositories that are unavailable at the moment of testing will throw errors Revisor can't do anything about. - </para> - </listitem> - <listitem> - <para> - If the directories <filename>revisor-yumcache/</filename> and <filename>revisor/</filename> in <filename>/var/tmp/</filename>, the default working directory, are not writeable for the user then YUM will throw permission denied errors. - </para> - <para> - Remove <filename>/var/tmp/revisor/</filename> and <filename>/var/tmp/revisor-yumcache/</filename> or run the command with root permissions. - </para> - </listitem> - </itemizedlist> - </para> - </formalpara> - </section> - - <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases-Compose_Results"> - <title>Requirements for Compose Results</title> - <para> - Although heavily dependent on Anaconda for this part, these are still requirements - </para> - - <formalpara> - <title>ld-linux.so.2</title> - <para> - In the <filename>initrd.img</filename> of the composed product, if 32-bit, <filename>/lib/ld-linux.so.2</filename> (or any other version) should link to <filename>/lib/ld-2.9.so</filename> (or any other version). If <filename>/lib/ld-linux.so.2</filename> links to itself, the media will fail to install. - </para> - </formalpara> - <formalpara> - <title>How to test</title> - <para> - In a terminal, type the following command: - </para> - </formalpara> - <para> - <screen>$ <userinput>lsinitrd /path/to/initrd | grep ld-linux</userinput></screen> - </para> - <para> - See also: <ulink url="https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00115.…" /> - </para> - - </section> - </section> - - <section id="Revisor_Reference_Manual-Testing-Complex_Test_Cases"> - <title>Complex Test Cases</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Testing-Specific_Test_Cases"> - <title>Specific Test Cases</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Tips_and_Tricks.xml b/doc/Reference_Manual/en-US/Reference_Manual-Tips_and_Tricks.xml deleted file mode 100644 index 8b785ee..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Tips_and_Tricks.xml +++ /dev/null @@ -1,47 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Tips_and_Tricks"> - <title>Tips and Tricks</title> - <para> - para - </para> - - <section id="Revisor_Reference_Manual-Tips_and_Tricks-The_spin-kickstarts_Package"> - <title>The spin-kickstarts Package</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Tips_and_Tricks-Even_More_Debugging"> - <title>Even More Debugging</title> - <para> - something about using -x to buildinstall scripts - </para> - </section> - - <section id="Revisor_Reference_Manual-Tips_and_Tricks-ksvalidator"> - <title>Kickstart Validator</title> - <para> - something about using -x to buildinstall scripts - </para> - </section> - - <section id="Revisor_Reference_Manual-Tips_and_Tricks-Using_Mirrormanager_For_Mirror_Redirection"> - <title>Using Mirrormanager for Mirror Redirection</title> - <para> - Something about using Mirrormanager to redirect you to the local mirror (so you do not have to edit YUM configuration files). - </para> - </section> - - <section id="Revisor_Reference_Manual-Tips_and_Tricks-The_localrepo_DNS_Alias"> - <title>Using The localrepo DNS Alias</title> - <para> - Something about using the localrepo DNS alias to point to your local mirror (either through real DNS or through /etc/hosts), so you do not have to edit the YUM configuration files. - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Tweaking_The_Build_Process.xml b/doc/Reference_Manual/en-US/Reference_Manual-Tweaking_The_Build_Process.xml deleted file mode 100644 index 4979285..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Tweaking_The_Build_Process.xml +++ /dev/null @@ -1,40 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Tweaking_The_Build_Process"> - <title>Tweaking the build process</title> - <para> - para - </para> - - <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Reusing_Existing_Installer_Images"> - <title>Reusing Existing Installer Images</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Building_The_Installer_Images_In_Mock"> - <title>Building The Installer Images in Mock</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Omitting-isomd5sum"> - <title>Omitting isomd5sums</title> - <para> - para - </para> - </section> - - <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Omitting-sha1sums"> - <title>Omitting SHA1SUMS</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Using_Kickstart.xml b/doc/Reference_Manual/en-US/Reference_Manual-Using_Kickstart.xml deleted file mode 100644 index f3e6ab2..0000000 --- a/doc/Reference_Manual/en-US/Reference_Manual-Using_Kickstart.xml +++ /dev/null @@ -1,118 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Reference_Manual-Using_Kickstart"> - <title>Using Kickstart</title> - <para> - Kickstart is a configuration file format for automating installation procedures. Or at least, it was, originally. Nowadays, kickstart files are used as input to the compose tools, including Revisor. - </para> - <para> - Revisor again is unique in that it does not require a kickstart file for input. The other tools only take kickstart configuration files. Revisor though allows most of what is in a kickstart file to be configured interactively in Graphical User Interface mode. - </para> - - <section id="Revisor_Reference_Manual-Using_Kickstart-How_Kickstart_Is_Used"> - <title>How Kickstart Is Used</title> - <para> - There's two cases in which a kickstart file is used differently. One is during the compose of installation media, and the other of course is during the compose of live media, or virtualization media. - </para> - - <section id="Revisor_Reference_Manual-Using_Kickstart-How_Kickstart_Is_Used-Installation_Media"> - <title>Installation Media</title> - <para> - In the case of installation media, the following settings are used: - </para> - <para> - <itemizedlist> - <listitem> - <formalpara> - <title><literal>repo</literal></title> - <para> - The <literal>repo</literal> command in kickstart is used when Revisor is configured to use the repositories configured in the kickstart file only. Use <literal>kickstart_repos = 1</literal> to enable this feature, or set the appropriate checkbox in the Revisor GUI. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title><literal>%packages</literal></title> - <para> - The <literal>%packages</literal> section in kickstart is used to determine the RPM payload on the installation media. It can include groups and packages, and exclude packages. It accepts wildcards, both in includes and excludes of packages (but not groups). - </para> - </formalpara> - </listitem> - </itemizedlist> - </para> - <note> - <title>@core and @base</title> - <para> - By default, groups @core and @base are included in the package manifest. You can specify @base to not be included, by using <literal>%packages --nobase</literal>, but @core cannot be excluded using a kickstart package manifest. - </para> - </note> - <para> - Using <literal>kickstart_exact</literal>, you can exclude @core and @base so that you need to explicitly select them in the kickstart package manifest. - </para> - <para> - Using <literal>kickstart_exact_nevra</literal> ... - </para> - </section> - </section> - - <section id="Revisor_Reference_Manual-Using_Kickstart-The_Kickstart_Package_Manifest"> - <title>The Kickstart Package Manifest</title> - <para> - para - </para> - - <formalpara> - <title>Group @core</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Group @base</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Including groups of packages</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Including a single package</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Excluding a single package</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Using wildcard matches</title> - <para> - para - </para> - </formalpara> - - <section id="Revisor_Reference_Manual-Using_Kickstart-Using_Kickstart_With_Package_NEVRA"> - <title>Using Kickstart with Package NEVRA</title> - <para> - para - </para> - </section> - - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Compose_Process_Details.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Compose_Process_Details.xml new file mode 100644 index 0000000..6b12e6c --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Compose_Process_Details.xml @@ -0,0 +1,431 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Compose_Process_Details"> + <title>Compose Process Details</title> + <para> + This chapter lists the details of the compose process as well as dives deep into the features of Revisor. + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Overview"> + <title>Overview</title> + <titleabbrev id="Compose_Process_Details-Overview">Overview</titleabbrev> + <para> + Of course, the compose process for installation media is a little different then the compose process for live media. + </para> + <para> + When composing, Revisor starts out doing the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Revisor initiates and loads plugins, options, and defaults. At this point, Revisor has a so-called <emphasis>ConfigStore</emphasis> that holds all options Revisor knows about. + </para> + </listitem> + <listitem> + <para> + Revisor reads the options from the command-line. + </para> + </listitem> + <listitem> + <para> + Revisor reads the configuration file specified with the <code>--config</code> command-line parameter, or uses it's builtin default, <filename>/etc/revisor/revisor.conf</filename>. + </para> + </listitem> + <listitem> + <para> + Revisor reads the global <code>[revisor]</code> section for all settings available in it's <emphasis>ConfigStore</emphasis> and sets those configured in the global section. Remember that if an option is not available in the <emphasis>ConfigStore</emphasis> but is configured in the global configuration section, it is ignored. + </para> + </listitem> + <listitem> + <para> + If a model is specified in the configuration file's global section <code>[revisor]</code>, Revisor will set that model to be used and loads it. + </para> + </listitem> + <listitem> + <para> + If a model has been specified on the command-line, with option <code>--model</code>, Revisor loads that model. + </para> + </listitem> + <listitem> + <para> + When loading the model, Revisor again iterates over all the settings that are in the <emphasis>ConfigStore</emphasis>, checks if the setting has been configured in the model section, and adjusts the setting in the <emphasis>ConfigStore</emphasis> if necessary. Again remember that if the <emphasis>ConfigStore</emphasis> does not know about one or the other option already, that setting is ignored. + </para> + </listitem> + <listitem> + <para> + Now that the defaults and configuration file settings have been applied to the <emphasis>ConfigStore</emphasis>, it is time for Revisor to look at the options specified on the command-line to see if you wanted to override anything. + </para> + </listitem> + <listitem> + <para> + While loading each configuration setting available in the global <code>[revisor]</code>, model-specific sections and/or command-line, Revisor checks every settings against a function that is specifically written to check such setting. For example, the label of an ISO cannot be longer then 32 characters. + </para> + </listitem> + <listitem> + <para> + Especially in CLI mode, these settings build up the task list for Revisor. If there's nothing to do, Revisor will throw an error explaining what's missing. If there's things to do that cannot be done in one run, Revisor will throw an error explaining that. + </para> + </listitem> + <listitem> + <para> + In Graphical User Interface mode however, if the settings loaded so far are all OK, the GUI will start. Since you can still adjust a few settings from within the GUI, the settings loaded so far will be the defaults for configuration settings that have a dialog for you to adjust them with, throughout the rest of the process. + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Installation_Media"> + <title>Installation Media</title> + <para> + As we've explained before, composing installation media is a little different then composing live media. That's not just because installation media should start an installation procedure and live media should show you a nice, shiny, fully-functional Desktop. + </para> + <para> + For one, installation media allows split media. This means that Revisor can span the payload of the product over multiple ISO images or multiple discs, if you will. When composing installation media, Revisor basically does the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Of course, Revisor goes through the loading of configuration options mentioned in the <xref linkend="Revisor_Reference_Manual-Compose_Process_Details-Overview" endterm="Compose_Process_Details-Overview" />. + </para> + </listitem> + <listitem> + <para> + When you're done specifying options in the GUI, or when Revisor thinks it can go ahead using the options specified in CLI mode, it takes the list of packages selected from either the GUI or the kickstart <code>%packages</code> manifest. + </para> + <para> + Not getting too deep into details here, yet, because some of these things are routines shared with other composing modes, but here's a few additional considerations Revisor makes when doing the package selection. + </para> + <para> + <itemizedlist> + <listitem> + <para> + Normally, a kickstart <code>%packages</code> manifest only allows you to select package <emphasis>names</emphasis>. With Revisor though, you can select exact package <emphasis>NEVRA</emphasis> to select a certain version or architecture for the package that you want. Additionally, if a package is not available, Revisor searches the <emphasis>Provides</emphasis> of the available packages. + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Live_Media"> + <title>Live Media</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode"> + <title>Respin Mode</title> + <para> + Revisor has a respin mode that in some aspects differs from the regular routines. It is intended to reflect behaviour of tools in use by the Fedora Project Release Engineering team as closely as possible. + </para> + <para> + Re-Spin mode only affects installation media products. + </para> + <para> + In Re-Spin mode, the way the RPM payload is determined from kickstart differs from Revisor's normal procedures. See <xref linkend="Revisor_Reference_Manual-Using_Kickstart" /> for more details on using a kickstart package manifest. + </para> + <para> + A kickstart file's so-called <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-package_manifest" /> usually looks like: + </para> + <para> + <screen>%packages +@group1 +@group2 --nodefaults +@group3 --optional +package1 +package2 +-package3 +%end</screen> + </para> + <para> + Which tells us the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Include all mandatory and default packages from group1 + </para> + </listitem> + <listitem> + <para> + Include all mandatory packages from group2 + </para> + </listitem> + <listitem> + <para> + Include all mandatory, default and optional packages from group3 + </para> + </listitem> + <listitem> + <para> + Include package1, and package2 + </para> + </listitem> + <listitem> + <para> + Exclude package3 + </para> + </listitem> + </itemizedlist> + </para> + <para> + Depending on how you use this instructions or information, there is a slight difference in the package set that ends up on the media you compose. + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode-Selecting_Groups"> + <title>Selecting Groups</title> + <para> + Selecting groups has the following logic: When you load a repository you may also load the groups file (often referred to as 'comps' or 'comps.xml'). This comps file is an XML file with categories, groups (per category), and per group: + </para> + <para> + <itemizedlist> + <listitem> + <para> + a list of mandatory packages. If you select or include the group, these packages come with it. + </para> + </listitem> + <listitem> + <para> + a list of default packages. If you select or include the group, these packages will come with it as a default. If you only want the mandatory, minimum set of packages for this group, in a kickstart package manifest append <code>--nodefaults</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Deselect all packages</emphasis>. + </para> + </listitem> + <listitem> + <para> + a list of optional packages. If you select a group you have not yet selected these packages. To select the optional packages of a group, in a kickstart package manifest append <code>--optional</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Select all optional packages</emphasis>. + </para> + </listitem> + <listitem> + <para> + a list of conditionals. If you select this group, these conditionals are thrown into the package sack and transaction information and include or exclude other packages. Suppose you select the '@nl-support' or “Dutch Support” group from the Languages or Localization category, you would end up with support for the Dutch language in all applications that have that kind of support. + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode-Select_Matching_Packages"> + <title>Select Matching Packages</title> + <para> + This is the logic Revisor applies when running in Re-Spin mode (on the CLI, specify <code>--respin</code>). It imitates the behavior pungi has, and thus enables you to copy that behavior. Note that <code>--respin</code> has other implications as well. + </para> + <para> + First of all, it iterates the groups in the kickstart package manifest. For each group, it appends the names of the mandatory packages to a list, and depending on the additional parameters specified with that group (<code>--nodefaults</code> or <code>--optional</code>), appends the names of the other packages in that group as well. + </para> + <para> + Then it iterates over the package names in the package manifest. These package names are appended to the same list of package names too. This includes package 'names' with some sort of wildcard (?, or *). + </para> + <para> + Then it iterates over all the excluded packages, appending each of those to the YUM configuration exclude list. + </para> + <para> + Now that Revisor has a very simple, flat list of package names, it uses YUM's internal matching logic 5 to get what packages in the repositories matched exactly (by name), matched (by wildcard) and did not match at all. Revisor then selects the exact matches and matches, adding them to the transaction. + </para> + </section> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving"> + <title>Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + </indexterm> + <para> + Dependency resolving is the area where some of the efficiency Revisor can gain for you comes from. While of course there is specific reasons to do things one way, or the other, most people I speak to about Revisor, it is not very clear why, or what Revisor does in this area. First of all, there's two ways of resolving dependencies: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Inclusive Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + <secondary>Inclusive</secondary> + </indexterm> + <para> + Iterate all packages in the transaction and list their requirements, then for each of those requirements, find all packages that provide a matching capability, add those packages to the transaction, and don't forget to add the requirements those packages have themselves, back into the pile of (unmet) requirements. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Exclusive Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + <secondary>Inclusive</secondary> + </indexterm> + <para> + Iterate all the packages and for each of the requirements found, find the best package that meets the requirement. This is also YUMs default behavior. Anaconda uses YUM during the installation, and this is the behaviour of YUM used during the installation. + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive"> + <title>Inclusive Dependency Resolving</title> + <para> + Hypothetically, you could describe inclusive dependency as follows: + </para> + <para> + <screen>final_packages = [] +more_to_do = True +while more_to_do: +more_to_do = False +for package in packages: + if package in final_packages: + continue + + dependencies = find_package_dependencies() + for dependency in dependencies: + pulled_in_package = pull_in_dependency() + if pulled_in_package not in final_packages: + packages.append(pulled_in_package) + more_to_do = True</screen> + </para> + <para> + So, what does this mean? Basically, it means that if there is a requirement for a capability, all packages providing that capability are being pulled in. Now imagine package 'foo' requires capability 'web-client'. There's a number of packages providing that capability, right? So you get Firefox, lynx, elinks, konqueror, safari, Netscape, Internet Explorer, emacs, for free! All of those pull in their own dependencies also, of course. + </para> + <note> + <para> + If you catch this before it catches you, you can prevent the packages from being pulled in during dependency resolving by not making the package available in the <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-Package_Sack" /> in the first place, using the <literal>-firefox</literal> syntax in the kickstart package manifest, and setting <literal>kickstart_uses_pkgsack_excludes</literal> to 1. + </para> + </note> + <note> + <para> + You may have thought of it; pulling in packages this way may give you a package set (or <emphasis>RPM payload</emphasis>) that has conflicting packages. Imagine package <application>foo</application> requiring capability <application>bar</application>, which is provided by two packages that conflict with one another (either on explicit <literal>Conflicts:</literal> RPM header or file level). Both will be pulled in, hence disabling you to install everything (<literal>'*'</literal> or -previously- <literal>@Everything</literal> in the kickstart package manifest). + </para> + </note> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Makes_Sense"> + <title>When This Makes Sense</title> + <para> + If you are composing a large distribution of which 3 million users in even so many different situations having so many different expectations and desires, you will want this behaviour, since you won't be able to determine which one of the packages for each capability someone in that group wants, and which one may not want. Or, in case of upgrades, what the system needs. Shipping them all on the same media is the best solution in these cases. + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Does_Not_Make_Sense"> + <title>When This Does Not Make Sense</title> + <para> + <itemizedlist> + <listitem> + <para> + When creating installation media to be installed unattended, or to be used in conjunction with deployment strategies + </para> + </listitem> + <listitem> + <para> + When creating installation media to be upgrading PCs you have controlled from the beginning, such as in a company + </para> + </listitem> + <listitem> + <para> + Installation for a small group of users or systems + </para> + </listitem> + <listitem> + <para> + When creating minimal installation media, or media with a minimal RPM payload. + </para> + </listitem> + <listitem> + <para> + When creating installation media that is to be used with installing "Everything" in the RPM payload. + </para> + </listitem> + </itemizedlist> + </para> + </section> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Exclusive"> + <title>Exclusive Dependency Resolving</title> + <para> + Exclusive dependency resolving is what YUM does when you execute a <application>yum install</application>. Unless you've specified one of the packages satisfying any of the dependencies in the transaction, YUM is going to look up the best match for you. This results in the installation of only one package providing the requirement(s) of other packages, rather then all packages providing said requirement being installed. + </para> + <para> + As an example, imagine you install a package foo which requires capability web-client. Using exclusive dependency resolving, YUM would select one package providing the web-client capability whereas inclusive dependency resolving would include all packages providing the web-client capability. + </para> + <para> + During the installation procedure, one of the major features of installation media, anaconda is going to use YUM dependency resolving to satisfy all the dependencies. + </para> + <note> + <title>Installation Procedure !== Upgrade Procedure</title> + <para> + Note that an installation procedure is not the same as an upgrade procedure. With an installation procedure for example, you have control over the partitioning layout whereas with an upgrade procedure, you have none. More importantly, during an upgrade procedure, the (already installed) system has an existing package set which needs to be updated/upgraded and thus could possibly introduce dependency resolving problems, because of third party packages installed on the system, or because the media used to upgrade the system with does not contain the software packages needed to complete the upgrade RPM transaction. + </para> + </note> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Copying_Arbitrary_Files_Onto_The_Media"> + <title>Copying Arbitrary Files Onto the Media</title> + <para> + With <literal>--copy-dir</literal>, you can specify a path Revisor should copy onto the media. + </para> + <formalpara> + <title>Installation Media</title> + <para> + In the case of installation media, the path specified with <literal>--copy-dir</literal> will be copied recursively to the <filename>files/</filename> sub-directory at the root of the ISO image (or the first ISO image if you compose split media). + </para> + </formalpara> + <para> + A few use-case examples: + </para> + <para> + <itemizedlist> + <listitem> + <para> + If one kickstart profile is not enough for you to deploy the product onto your systems, create a directory that holds multiple kickstart files and specify the path to that directory using <literal>--copy-dir</literal>. The kickstart files now end up available to the installation procedures as <filename>cdrom:/files/*.ks</filename>, and can thus be used by specifying them on the kernel cmdline (<code>ks=cdrom:/files/profile1.ks</code>), or, when used in combination with <literal>--isolinux-cfg</literal> from the <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin" endterm="Isolinux_Plugin" />, can be added as an option in the isolinux menu. + </para> + </listitem> + <listitem> + <para> + If you have files or scripts that need to be copied onto, or run on, the installed system before it attempts to reboot and operate normally, you can use <literal>--copy-dir</literal> to make these files and scripts available during the installation and copy or execute them from either <code>%pre</code> or <code>%post</code> scripts. + </para> + </listitem> + </itemizedlist> + </para> + <formalpara> + <title>Live Media</title> + <para> + In the case of live media, the path specified with <literal>--copy-dir</literal> will be copied recursively onto the root directory (<filename>/</filename>) of the live media filesystem (which is probably loop-mounted onto <filename>/var/tmp/revisor/</filename>). + </para> + </formalpara> + <para> + If, for example, you want to copy a home directory onto the live media, and the home directory you want to copy is at <filename>/home/user1/</filename> on the composing system, you copy this directory so that the root of that new directory has a sub-directory <filename>home/</filename> which in turn contains a sub-directory <filename>user1/</filename>: + </para> + <para> + <screen>$ <userinput>mkdir -p /tmp/something/home/</userinput> +$ <userinput>cp -a /home/user1 /tmp/something/home/.</userinput> +$ <userinput>revisor [options] --copy-dir /tmp/something/</userinput></screen> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Cleaning_Up"> + <title>Cleaning Up</title> + <para> + Revisor tends to clean up after itself by default. If a product compose succeeds, you (probably) don't need to change this default behaviour. However, by default, Revisor tends to leave the YUM cache directories untouched. This is to prevent you from having to download all the packages a second, third or more times when you run another compose. + </para> + <para> + To change this default behaviour, Revisor has an option <literal>--clean-up</literal>. The default value for this option is <literal>1</literal>, meaning Revisor will clean up it's temporary, compose-specific files, but no files that could be re-used. Specifying <literal>--clean-up=0</literal> will cause Revisor to leave everything behind and not clean anything up at all. This is most ideal for troubleshooting purposes, where one needs to examine the temporary, compose-specific files and see what went wrong. To clean up everything however, because for example you might be low on disk-space, use <literal>--clean-up=2</literal>. Revisor will then also clean up the files that could be re-used. + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Cleaning_Up-Exception-to-the-Rule"> + <title>Exception to the Rule</title> + <para> + There's one exception to the rule of cleaning up. <filename>/var/tmp/revisor/</filename>, or put more accurately, the path specified as the <code>installroot</code> in the YUM configuration file configured with the model used to compose the product, will not be cleaned up afterwards. When composing live media, this directory may still be in use as a mount-point for the live media filesystem. Removing this directory recursively in these cases would not make sense. + </para> + </section> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Configuration.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Configuration.xml new file mode 100644 index 0000000..647706f --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Configuration.xml @@ -0,0 +1,280 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Configuration"> + <title>Configuration</title> + <para> + Revisor configuration can be performed using <xref linkend="Revisor_Reference_Manual-Configuration-Files" />, or through <xref linkend="Revisor_Reference_Manual-Configuration-Command-line_Options" />. + </para> + + <section id="Revisor_Reference_Manual-Configuration-Files"> + <title>Configuration Files</title> + <para> + Revisor uses configuration files for a large part of it's operations. These files mostly reside in <filename>/etc/revisor/</filename>. There is two types of files Revisor uses: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Revisor Configuration Files</title> + <para> + Revisor configuration files, such as <filename>/etc/revisor/revisor.conf</filename>, contain information and settings unique to Revisor. A Revisor configuration file is where you specify default options, and include information on different products you want to compose. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>YUM Configuration Files</title> + <para> + YUM configuration files, such as the files in <filename>/etc/revisor/conf.d/</filename>, contain configuration for YUM. To be more precise, Revisor doesn't even handle the files (it let's YUM do so). The files in <filename>/etc/revisor/conf.d/</filename> practically contain the same information as <filename>/etc/yum.conf</filename> combined with the files in <filename>/etc/yum.repos.d/</filename> (but not exactly the same content!). + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + + <section id="Revisor_Reference_Manual-Configuration-Files-_etc_revisor_revisor.conf"> + <title><filename>/etc/revisor/revisor.conf</filename></title> + <para> + The default Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. This configuration file contains two sections: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title><literal>[revisor]</literal></title> + <para> + The global section. Options specified in this section apply to all the models defined in this configuration file. + </para> + </formalpara> + <para> + See also: <xref linkend="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration" /> + </para> + </listitem> + <listitem> + <formalpara> + <title><literal>[<replaceable>model</replaceable>]</literal></title> + <para> + Model configuration. One section per <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-model" />. + </para> + </formalpara> + <para> + See also: <xref linkend="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration" /> + </para> + </listitem> + </orderedlist> + </para> + <para> + Model sections basically define a single product. Amongst other things, the distribution name, release version, architecture for the product to be composed and what YUM configuration file to use, are (often) defined on a per-model basis. There is a large number of settings available for models, and they are all related to how the product is going to look like. The product name, the location of the RPM payload for installation media, the ISO label, the YUM configuration file to use, are all model settings. + </para> + <para> + Using models, you can reproduce the outcome of the compose process, a <emphasis>product</emphasis>, simply by not changing the model configuration anymore. If you want something different, you can just add another model section, and name it differently. + </para> + <para> + To see what models are available with the Revisor standard package, use: + </para> + <para> + <screen>$ <userinput>revisor --list-models</userinput></screen> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Files-_etc_revisor_conf.d_"> + <title><filename>/etc/revisor/conf.d/</filename></title> + <para> + The default YUM configuration files used by Revisor. In a model configuration section, the <literal>main =</literal> setting points to one of the YUM configuration files in <filename>/etc/revisor/conf.d/</filename> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Files-Updates"> + <title>Updates to Configuration Files</title> + <para> + The Revisor packages are not allowed to overwrite files in <filename>/etc/</filename>, and they should thus not do so. If an update to Revisor is installed on your system, files with the extension <literal>.rpmnew</literal> may be created --if you had changed anything in the file before applying the update. Since this world isn't perfect, configuration errors may exist in the configuration files shipped with Revisor. Please pay close attention to updates to these configuration files by examining the <literal>.rpmnew</literal> files. + </para> + <para> + You can use any file location (not just <filename>/etc/revisor/</filename>) for your own custom configuration. + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Files-Changing_Configuration_Files"> + <title>Changing Configuration Files</title> + <para> + If you are creating your own models off of the ones that ship with Revisor itself, please consider using an alternative configuration file (a file other then <filename>/etc/revisor/revisor.conf</filename>, or copy the original file for safekeeping. This way, you can always return to a working, sample configuration file and test whether it is Revisor causing errors, or configuration mistakes. + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration"> + <title>Global and Model Configuration</title> + <para> + The default Revisor configuration file, <filename>/etc/revisor/revisor.conf</filename> consists of multiple sections (the file is in .INI format). One is the <literal>[revisor]</literal> global section, where you specify configuration options that apply to each other section or <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-model" />. + </para> + <para> + The options specified in the global and model configuration sections apply to the Revisor compose in the following order: + </para> + <para> + <orderedlist> + <listitem> + <para> + The options from the global section are read, tested and set. + </para> + </listitem> + <listitem> + <para> + The options from a model section are read, tested and set, regardless of whether the global section had caused the setting to be set to a certain value already. + </para> + </listitem> + </orderedlist> + </para> + <para> + For example, if you know all the models in a configuration file are optical live media products, the configuration sections could look like the following: + </para> + <para> + <screen>[revisor] +# Optical live media for all models +media_live_optical = 1 + +[model1] +main = /etc/revisor/conf.d/revisor-model1.conf +description = The model1 product +architecture = i386 +# This is already configured in the global section of +# this configuration file and can thus be removed. +#media_live_optical = 1</screen> + </para> + <note> + <title>When Running the GUI</title> + <para> + Note that when running Revisor in Graphical User Interface mode, you can still change a lot of the settings supplied by Revisor through the configuration files loaded. When you are running Revisor in GUI mode, the configuration files supply the defaults. + </para> + </note> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories"> + <title>YUM Repository Configuration</title> + <para> + The files in <filename>/etc/revisor/conf.d/</filename> are YUM configuration files. Revisor directs YUM to use these files during the compose process, and does not handle these files itself. This chapter lists a few tips and tricks. + </para> + <para> + Because these files are YUM Configuration files, you can configure anything that YUM supports. See <application>man yum.conf</application> for more details. + </para> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-releasever_and_basearch"> + <title>$releasever and $basearch</title> + <para> + When configuring a repository URL, make sure you do not use <replaceable>$releasever</replaceable> or <replaceable>$basearch</replaceable> variables. Since Revisor allows cross-composing distributions between different versions of the operating system, as well as different architectures, these variables need to be expanded to the value intended. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_a_Local_Mirror"> + <title>Using a Local Mirror</title> + <para> + If you have a local mirror of Fedora, you can use the <literal>baseurl</literal> configuration directive in each repository configuration section to tell YUM to use the local mirror. + </para> + <para> + Optionally, you can also disable the <literal>mirrorlist</literal>, preferably by outcommenting it, so that YUM will only use the local mirror. + </para> + <para> + The default <literal>baseurl</literal> uses <literal>http://download.fedoraproject.org/</literal>. This location may or may not be suitable for you. If you have a local mirror, you might want to change this setting here, or add your mirror to Fedora Project's Mirrorlist. + </para> + <note> + <title>Adding your local mirror to the Mirrorlist</title> + <para> + You can add your local mirror to the Mirrorlist, so that the Fedora Project mirrorlist redirects you to your local mirror. Additionally, systems in your local network(s) will be redirected to the local mirror. The local mirror does not have to be a public mirror in order to do so. See <ulink url="http://admin.fedoraproject.org/mirrormanager/" /> for more details. + </para> + </note> + <para> + Set each <literal>baseurl</literal> to the location of the repository on the local mirror. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_Local_Files"> + <title>Using Local Files</title> + <para> + If you have the repositories on your local filesystem, configure a <literal>baseurl</literal> of <filename>file://<replaceable>/path/to/repository/</replaceable></filename>. + </para> + <note> + <title>Make sure to supply the correct path</title> + <para> + Make sure to supply the correct path to the repository. <filename>file://</filename> is the "<emphasis>protocol</emphasis>" for the location, and the location is <filename><replaceable>/path/to/repository/</replaceable></filename>. Put together, you have <emphasis>three</emphasis> slashes. + </para> + </note> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_a_DVD"> + <title>Using a DVD</title> + <para> + A DVD does not contain enough packages to rebuild the installer images. If you are using a DVD and you want to rebuild the installer images, you will need to have a network connection and a mirror you can reach. + </para> + <para> + There is a list of required packages, but since the packages change per release and may change in the middle of the release cycle as well, we cannot hand you a list that just works. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Adding_Third_Party_Repositories"> + <title>Adding Third Party Repositories</title> + <para> + When adding a third party repository, make sure you add the correct release version as well as architecture to the Revisor YUM configuration file. Verify the location for the <literal>baseurl</literal> and/or <literal>mirrorlist</literal> you configure manually or through YUM. Make sure you expand any <literal>$releasever</literal>, <literal>$basearch</literal> and <literal>$arch</literal> variables. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Creating_Your_Own_Repository"> + <title>Creating Your Own Repository</title> + <para> + Creating your own repository is relatively simple. You take a directory, dump some RPM packages in it, and run <application>createrepo</application>. See <literal>man createrepo</literal> for more information. + </para> + <para> + People often wonder how Revisor handles comps.xml group files. + </para> + <para> + When you create your own repository, follow the directions in <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Adding_Third_Party_Repositories" /> to add the repository configuration to Revisor's YUM configuration, since your own repository is a third party repository as well. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting"> + <title>Testing & Troubleshooting the YUM Configuration</title> + <para> + Before you use the (modified) configuration file, take it for a test run. + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Configuration-Configuring_A_Proxy"> + <title>Configuring A Proxy Server</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Command-line_Options"> + <title>Command-line Options</title> + <para> + With the command-line options available, you can configure options that either override what is in the configuration file or have simply not been configured using the configuration file. With the default configuration files that come with the <application>revisor-cli</application> package for example, no media products have been pre-configured in the default section. In the <application>revisor-unity</application> package however, some default configuration has been applied so that Fedora Unity Re-Spins actually create CD, DVD and Rescue ISO images as well as the Installation Tree and include the sources. + </para> + <para> + Only some configuration options have CLI parameters. Use <application>revisor --help</application> to see a complete list of configuration options you can supply on the command line. + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Development.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Development.xml new file mode 100644 index 0000000..9df83c1 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Development.xml @@ -0,0 +1,220 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Development"> + <title>Development</title> + <para> + This chapter sheds some light on development of Revisor, such as different branches and maintenance policies, versioning schemas, etcetera. + </para> + <para> + This part of the documentation relies on whether you have <application>sudo</application> set up properly. If you have not, you're on your own. + </para> + + <section id="Revisor_Reference_Manual-Development-Running_Revisor_from_Source"> + <title>Running Revisor from Source</title> + <para> + The latest code in GIT can be built into a RPM you can install but one of the advantages of having the complete source tree is that you can run it directly from that source tree so that when you pull in the next updates you do not have to rebuild the RPM. Note that we do not bump the version number for every little change we make, and as such the RPM built does not allow you to use <literal>rpm -Uvh</literal> or <literal>rpm -Uvh --oldpackage</literal>. Of course, Revisor's Makefiles also allow <application>make install</application>, but that leaves a number of unmanaged files on your computer you would have to track down manually in order to remove Revisor completely. + </para> + <warning> + <title>Cannot have Revisor RPMs installed</title> + <para> + When running revisor from within the source tree, you cannot have any of the Revisor packages installed. Having Revisor RPM packages installed regardless will mess up the GIT repository or source tree. + </para> + </warning> + <para> + To run Revisor from within the source tree, checkout the master branch, and run the <filename>./switchhere</filename> script: + </para> + <para> + <screen>$ <userinput>./switchhere</userinput></screen> + </para> + <para> + The <filename>./switchhere</filename> script does the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Symlink <filename>/etc/revisor/</filename> to <filename><replaceable>$PWD</replaceable>/conf/</filename> so that <filename>/etc/revisor/revisor.conf</filename>, the primary configuration file, and <filename>/etc/revisor/conf.d/</filename>, the configuration directory, are valid (the symlink causes the actual file and directory to be found in <filename><replaceable>$PWD</replaceable>/conf/</filename>) + </para> + </listitem> + <listitem> + <para> + Create the <filename>/usr/share/revisor/</filename> directory so that a couple of symlinks can be created from within that directory: + </para> + </listitem> + <listitem> + <para> + In Revisor 2.1.0 (development version in branch master), this includes: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/revisor/modgui/glade/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/revisor/modgui/glade/pixmaps/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + <listitem> + <para> + In Revisor 2.0.5 (branch F-7, F-8 or EL-5), this includes: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/glade/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/glade/pixmaps/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + <listitem> + <para> + In Revisor 2.1.0, also create symlinks from within the appropriate <filename>/usr/share/man/man<replaceable>$x</replaceable>/</filename> directories to the source for these man pages in <filename><replaceable>$PWD</replaceable>/doc/</filename>. + </para> + </listitem> + </itemizedlist> + </para> + <para> + From this moment on, you should be able to run: + </para> + <para> + <screen>$ <userinput>./revisor.py</userinput></screen> + </para> + <note> + <title>Root privileges required</title> + <para> + Note that revisor needs root privileges to run, and that you'll need to sudo or su-c to gain those. Use here whatever you find the most convenient; Revisor though should have a nice error message when run without those privileges. + </para> + </note> + + <section id="Revisor_Reference_Manual-Development-Running_Revisor_from_Source-Required_Packages"> + <title>Installing the Required Packages</title> + <para> + To be able to run Revisor from within the source tree, you'll need to install the required packages for each component, of course. + </para> + <para> + To get a current list of those packages, use: + </para> + <para> + <screen>$ <userinput>rpmquery --specfile --qf="%{REQUIRES}\n" revisor.spec | sort | uniq | xargs -n 1 repoquery --requires --alldeps --resolve</userinput></screen> + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Development-Building_Revisor_Packages"> + <title>Building Revisor Packages</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Tickets"> + <title>Tickets</title> + <para> + bugzilla, trac + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Adding_A_New_Spin"> + <title>Adding a new spin or remix</title> + <para> + <orderedlist> + <listitem> + <para> + Add the appropriate models in the appropriate configuration file for Revisor. + </para> + </listitem> + <listitem> + <para> + Add the appropriate configuration file to the appropriate automake Makefile + </para> + </listitem> + <listitem> + <para> + Run autoreconf && ./configure && make rpm to verify the rpm building + </para> + </listitem> + <listitem> + <para> + Create the model's YUM configuration files with the following repositories: + </para> + <para> + <itemizedlist> + <listitem> + <para> + fedora, enabled, pointing to Everything + </para> + </listitem> + <listitem> + <para> + fedora-source, disabled, pointing to Everything + </para> + </listitem> + <listitem> + <para> + fedora-updates, enabled, pointing to the updates repository + </para> + </listitem> + <listitem> + <para> + fedora-updates-source, disabled, pointing to the updates repository + </para> + </listitem> + <listitem> + <para> + anaconda-updates, enabled, pointing to the anaconda updates repository + </para> + </listitem> + <listitem> + <para> + anaconda-updates-source, disabled, pointing to the ananconda updates repository + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + </orderedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Versioning_Schema"> + <title>Versioning Schema</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Release_Procedure"> + <title>Release Procedure</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Features.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Features.xml new file mode 100644 index 0000000..6321641 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Features.xml @@ -0,0 +1,175 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Features"> + <title>Features</title> + <para> + Revisor allows you to build and customize your own Remix, Re-Spin, Spin or even your own distribution, based on Fedora and derivative distributions such as Red Hat Enterprise Linux and CentOS. + </para> + <para> + Revisor builds installation media, live media, installation trees, cobbler distro's and profiles, virtualization images and more. + </para> + + <section id="Revisor_Reference_Manual-Features-Installation_Media"> + <title>Installation Media</title> + <para> + Installation media is what you use to install a system with. The installation media composed will allow you to go through the installation process, answering a number of questions (either manually or through kickstart), and ends up in a system running the distribution you install. + </para> + <para> + Composing installation media using the Revisor GUI allows you to choose the media (CD, or DVD), the packages to be included on the media (also called <emphasis>RPM payload</emphasis>). + </para> + <para> + Using the command-line interface, Revisor also allows you to choose DVD Duallayer and single- or dual-layer Bluray. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Installation_Trees"> + <title>Installation Trees</title> + <para> + Installation trees are typically used in environments where a distribution needs to be deployed over multiple systems, or is very volatile. Installation trees are often made accessible through HTTP or FTP protocols, in one place, and do not have as much overhead (in creating .iso files, and burning those to optical media to distribute them). + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Live_Media"> + <title>Live Media</title> + <para> + Live media often is a perfect showcase for an Operating system, Desktop Environment or any other thing you want to show. Also, since Live media is read-only, live media perfectly allows for a kiosk system, a system that may change while it's running, but restores all original settings when rebooted. + </para> + <para> + Live media is also installable. You start out with a system and boot it from live media, then choose to install the live media. This however is inferior to real installation media, but is convenient if you happen to like what you see when running from live media. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Reproducibility"> + <title>Reproducibility</title> + <para> + Media composed with Revisor is extremely reproducible. Using <literal>kickstart_exact_nevra</literal>, you can even select specific versions of packages to be included on the product. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Consistency"> + <title>Consistency</title> + <para> + When composing different types of media, such as CDs and DVDs, Revisor composes these discs in one run, making the different media completely consistent. <application>pungi</application> would require you to run twice, once for CDs, and once for DVDs. This is because <application>pungi</application> uses the <literal>part / <replaceable><size></replaceable></literal> kickstart configuration directive to set the maximum size of the media, and has no option to override the size on the command-line, nor to compose a certain set of media (it all depends on the size). + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Flexibility"> + <title>Flexibility</title> + <para> + Over the years, Revisor has been adopted to serve a large number of use-cases, where use-cases stretch from media being composed as efficient as possible, as robust as possible, specific deployment needs and expectations, and to match the Fedora Project Release Engineering tools' behaviour. All this allows you to configure a lot, and thus customize a lot, making Revisor more of a flexible framework. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Graphical_User_Interface"> + <title>Graphical User Interface</title> + <para> + Revisor has a Graphical User Interface or GUI, in addition to the Command Line Interface or CLI, which makes Revisor more accessible to users then the other tools, which are CLI only. Most people only know of Revisor through the GUI, and may think there is no CLI to Revisor. Only when it comes down to many of the additional features that Revisor has, and that do not fit in a simplified GUI, one gets down with it using the CLI. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Open_Development_Community"> + <title>Open Development Community</title> + <para> + Revisor has one of those old-fashioned Free and Open Source Software development communities, allowing anyone to make a contribution to Revisor. In fact, Revisor has not bounced a single patch since the project started. Therefor, it improves faster then any of the other compose tools, and is better adaptible to your needs and expectations, because unlike the other utilities, Revisor is not limited to use-cases that apply to Fedora Project Release Engineering. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Plugin_System"> + <title>Plugin System</title> + <para> + Revisor has a plugin system so that you can easily extend Revisor. This plugin system gives you full control over the Revisor procedures, and hands you off anything Revisor knows about the compose process. There's are multiple plugins available from upstream as well. To give you an example, the ability to replace <filename>isolinux.cfg</filename> after the compose is done, is a plugin. See <xref linkend="Revisor_Reference_Manual-Plugins" /> for more information. + </para> + + <para> + Current plugins included with Revisor include: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Cobbler_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Rebrand_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Reuse_Installer_Images_Plugin" /> + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Extraneous_Debugging"> + <title>Extraneous Debugging</title> + <para> + Revisor has extraneous debugging, which enables you, as well as the supporters and Revisor's developers, to trace down what happens exactly, and where anything might go wrong. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Using_YUM_Configuration_Files"> + <title>Using YUM Configuration Files</title> + <para> + Revisor uses YUM configuration files, where everyone else is not. With using YUM configuration files however, the control you have is nearly limitless. With all the features in YUM already, using it's configuration file format and letting YUM itself work with those allows Revisor to do a lot of cool things without doing anything itself: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Excluding packages from repositories</title> + <para> + Excluding packages from repositories means a great deal. Not having them exist in the <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-Package_Sack" /> ensures the package will not end up in the product. This may be what you want for maybe just a few, or maybe an awful lot of packages. + </para> + </formalpara> + <para> + Using the alternative configuration file format, kickstart, in use by every other compose tool, and the <literal>repo</literal> configuration directive that is available with kickstart, you can exclude packages using the <literal>--exclude=</literal> parameter to the <literal>repo</literal> configuration directive. However, that parameter does not allow wildcard matches. + </para> + </listitem> + <listitem> + <formalpara> + <title>Including only a certain (set of) package(s)</title> + <para> + Including only a certain package, or certain set of packages is valuable when a lot of packages exist in the repository configured, but you only need one or two. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Concurrent use of baseurl(s) and the mirrorlist</title> + <para> + Like during normal YUM operations, the baseurl(s) and the mirrorlist configured for a repository are used concurrently. This is not possible with the kickstart configuration directive <literal>repo</literal>, which takes either <literal>--baseurl</literal> or <literal>--mirrorlist</literal>, but not both. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Repository priorities</title> + <para> + Settings available with YUM are available within Revisor as well, like repository priorities. Using repository priorities, you can have YUM decide to pull a package from the repository with a higher priority (a lower priority number) rather then a repository with a lower priority. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>YUM Plugins</title> + <para> + YUM plugins, such as <application>yum-fastestmirror</application>, <application>yum-fedorakmod</application>, are available, giving you even more control over the behaviour of YUM. + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + </section> +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Frequently_Asked_Questions.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Frequently_Asked_Questions.xml new file mode 100644 index 0000000..7e97e0e --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Frequently_Asked_Questions.xml @@ -0,0 +1,54 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Frequently_Asked_Questions"> + <title>Frequently Asked Questions</title> + <para> + para + </para> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-How_Does_Revisor_Handle_Comps"> + <title>How Does Revisor Handle Comps?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-What_Are_Installer_Images"> + <title>What Are Installer Images?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Pungi"> + <title>What is the relationship between Revisor and Pungi?</title> + <para> + Where pungi builds a bunch of RPMs into ISO images and installation trees through one single procedure, perfect for Release Engineering on something like the Fedora Project, Revisor does it different entirely. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Livecd-tools"> + <title>What is the relationship between Revisor and livecd-tools?</title> + <para> + Revisor depends on livecd-tools for the composing of live media. Creating the filesystem to install the packages to, turning that image file into a SquashFS file, and applying the settings inside the chroot. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Why_Rebuild_Installer_Images"> + <title>Why Rebuild Installer Images?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-How_do_I_create_an_updates.img"> + <title>How do I create an updates.img?</title> + <para> + para + </para> + </formalpara> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Installation.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Installation.xml new file mode 100644 index 0000000..f56855f --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Installation.xml @@ -0,0 +1,104 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Installation"> + <title>Installation</title> + <para> + This chapter contains the installation instructions for Revisor. + </para> + + <section id="Revisor_Reference_Manual-Installation-Packages"> + <title>Packages</title> + <para> + You can install Revisor using RPM packages from the repositories already configured on your system. + </para> + + <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor"> + <title><application>revisor</application></title> + <para> + Shorthand package for the Revisor GUI. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor-cli"> + <title><application>revisor-cli</application></title> + <para> + The CLI version of Revisor. This package is always installed, as it contains the Python code for Revisor's core. Installing just this package will give you the command-line version of Revisor, and prevents the graphical dependencies from the <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor-gui" /> package to be installed as well. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor-gui"> + <title><application>revisor-gui</application></title> + <para> + The GUI version of Revisor. This is the actual package containing the Graphical User Interface, as opposed to <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor" />. Depends on <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor-cli" />, and thus also installs the command-line version of Revisor. + </para> + </formalpara> + + <section id="Revisor_Reference_Manual-Installation-Packages-YUM-RHEL"> + <title>Red Hat Enterprise Linux 5 or higher</title> + <para> + On Red Hat Enterprise Linux 5 or higher, and derivatives, install the Extra Packages for Enterprise Linux (EPEL) repository. + </para> + <para> + Then, give the following command: + </para> + <para> + <screen># <userinput>yum install revisor</userinput></screen> + </para> + </section> + + <section id="Revisor_Reference_Manual-Installation-Packages-YUM-Fedora"> + <title>Fedora 7 or higher</title> + <para> + On Fedora 7 or higher, and derivatives, no additional repository configuration is required. + </para> + <para> + Give the following command: + </para> + <para> + <screen># <userinput>yum install revisor</userinput></screen> + </para> + <note> + <title>About EOL Releases</title> + <para> + Please bear in mind that Fedora releases that are past the point of End-Of-Life, approximatly 13 months after the initial release, are not supported anymore for use with Revisor. Also, the version of Revisor running on these EOL versions of Fedora are not supported anymore. + </para> + </note> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Installation-The_Latest_And_Greatest"> + <title>The Latest and Greatest</title> + <para> + The latest and greatest is available from GIT, at <ulink url="git://git.fedorahosted.org/revisor" />. To clone this repository, use: + </para> + <para> + <screen>$ <userinput>git clone git://git.fedorahosted.org/revisor/</userinput></screen> + </para> + <para> + Using the GIT clone, you have the several options to start using the latest and greatest: + </para> + <formalpara> + <title>Running directly from the source</title> + <para> + You can run directly from within the source tree. See <xref linkend="Revisor_Reference_Manual-Development-Running_Revisor_from_Source" /> for more information on how to do so. + </para> + </formalpara> + <warning> + <title>Installed packages and running from source</title> + <para> + Do not run Revisor from source while RPM packages have been installed. Files managed by a package will get created, moved and removed when using Revisor's source tree, and updates to the installed RPM packages will destroy these changes. + </para> + </warning> + <formalpara> + <title>Building your own packages</title> + <para> + You can create your own packages, so that you have all the benefits of RPM. See <xref linkend="Revisor_Reference_Manual-Development-Building_Revisor_Packages" /> for more information on how to do so. + </para> + </formalpara> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Introduction.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Introduction.xml new file mode 100644 index 0000000..561b37c --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Introduction.xml @@ -0,0 +1,71 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Introduction"> + <title>Introduction</title> + <para> + Revisor is a community product by Fedora Unity. Amongst other features, it allows the creation of installation media and live media in the easiest possible manner, through a click-and-go GUI. This chapter gives some insight on how and why Revisor was born, and how the product evolved since. + </para> + + <section id="Revisor_Reference_Manual-Introduction-History_Of_Revisor"> + <title>History of Revisor</title> + <para> + Revisor development started in December 2006, during the Fedora 7 development cycle, in which -you might recall- the Fedora Core repository, maintained by Red Hat, and Fedora Extras repository, mostly maintained by the community, were merged into one large repository being maintained by both community members as well as Red Hat employees -which are mostly community members hired by Red Hat -so community altogether. Before then Red Hat employees maintained Fedora Core -as the set of packages upstream for Red Hat's Enterprise product- and the community maintained a repository with additional software; Fedora Extras. Red Hat composed the Fedora distribution every once in a while, but the merge introduced the possibility for packages that were in Fedora Extras to be included in the main distribution, and for the community to also (co-)maintain the (former) Fedora Core packages that originally made up the distribution. + </para> + <para> + In addition to this huge merge of packages, Red Hat employees were also able to release the entire build process to the community, meaning that from the moment the source is committed up and until the release is announced, the entire process is open. Not that is was all behind closed doors or proprietary or anything, the community just couldn't really play with it as much. We now have koji (build system), mash (repository compose from build system products), bodhi (updates release system), livecd-tools (compose tool for live media) and pungi (compose tool for installation media). + </para> + <para> + Composing media was an obscure process up and until the moment these tools exposed the best way to compose (a set of) installation media. Fedora Unity had been building and releasing so-called Re-Spins1 regularly, but they were built using a not-so-very intelligent bash script. Like hundreds if not thousands of other parties that needed to build their own media one way or the other, the entire process was based on the best educated guess of what should happen. Luckily, in the FOSS world an educated guess is often a very good guess, despite the fact that one keeps learning even years after the original engagement. + </para> + <para> + When in December 2006 the compose tools hit a stage in which they were released to the public, Fedora Unity was eager to get these tools and study them and use them for composing their Re-Spins. Up and until then, Re-Spins were composed with the aforementioned bash script that didn't do much but trigger the appropriate commands in a sequence; There wasn't any dependency resolving between the packages included nor did we know exactly how a release was supposed to be composed -it was our educated guess of how it could happen. Although it often led to success, we've had many, many failed Re-Spins as well. With a handful of volunteers, you can imagine the amount of frustration that might give. Fedora Unity was eager to improve their Re-Spin process. + </para> + <para> + So, early February 2007, a number of Fedora Unity members attended “FUDCon 2007” in Boston, and presented a working GUI front-end to livecd-tools and pungi enabling regular users to also re-compose or re-spin the installation media and live media they had been getting from the Fedora Project. Revisor at this point just made it “as easy as possible”. Besides the possibilities of pungi and livecd-tools themselves, the wizard Revisor had apparently was very, very useful to mere mortals. From that point on, things took off. + </para> + <para> + Fedora Unity decided Revisor could accomplish more then just being a front-end to existing compose tools and enable someone to tweak a lot of settings as well. In March 2007, Revisor was rebuild from the ground up in March 2007 to allow a more flexible process, more dependent on the configuration directives it was given and less so on the processes of the existing tools. When in San Diego at the Red Hat Summit (early May 2007), Robert 'Bob' Jensen and Jonathan Steffan gave a presentation on “Customizing Fedora”, the responses were amazing. Since then Revisor has evolved from a front-end to existing tools to the complete compose tool it is today, with lots of configuration options for specific use-cases. + </para> + <para> + For users, Revisor is particularly useful because it has a GUI front-end wizard, which, with the defaults settings, will just succeed in getting a user the media he/she wants. If a user decides he needs little adjustment of the media, the GUI allows for selecting the most common options. If a user decides he needs some less common adjustments, the configuration options gives him very granular control -and as long as the documentation on all the options is sufficient, users will be able to make those less common adjustments. + </para> + <para> + For administrators on the other hand, Revisor is the tool that gives so much granular control over what happens, that it can serve almost every specific use-case. In this aspect, Revisor could potentially replace the compose tools administrators have been developing themselves with a consistent and flexible program flow. + </para> + <para> + This document should enable you to study the process of composing installation and live media, and comprehend the logic Revisor adds to that process. + </para> + </section> + + <section id="Revisor_Reference_Manual-Introduction-The_Installation_Media_Challenge"> + <title>The Installation Media Challenge</title> + <para> + When Fedora Unity first started doing these so-called Re-Spins, the challenge ahead could maybe be explained like this: + </para> + <para> + <emphasis>When a user downloads a Fedora release and installs the distribution, the user will need to download and install a number of updates. The “older” the release becomes, the more updates will be available, and the greater the total download size of these updates the user will need to download on top of the download size of the original release media.</emphasis> + </para> + <para> + “older” is in quotes on purpose, because really for an operating system -or “distribution” if you will- being released every 6 months, “old” is quite a relative concept. The number of updates available however, at any given time during the release cycle, may range from 0 right after the release (which has never happened before), to the total amount of packages installed on the user's system (often over 2000). You can imagine the size of these updates ranging from 0 MB to an astonishing 2GB(!), only 6 months after the initial release. + </para> + <para> + Some of us do not have the bandwidth capacity or enough data transfer quota to download this many extra, rather useless bits. In addition, some of us do not have an Internet connection at all, and thus benefit getting the updates from Re-Spins directly. + </para> + <para> + The use of updates in Re-Spins has several more beneficial side-effects, which we'll explain in more detail later on in this document. Long story short; If for some reason the software used to compose the media (the release) with does not work for your hardware or your specific needs, updated software incorporated in the composed installer images might resolve that problem. + </para> + <para> + This is the original challenge the Fedora Unity team resolved a long time ago, and is at the base of what Revisor does nowadays. + </para> + </section> + + <section id="Revisor_Reference_Manual-Introduction-The_Live_Media_Challenge"> + <title>The Live Media Challenge</title> + <para> + Back in the day Fedora Core 5 was the most recent release, Fedora Unity created so-called live media using Kadischi. In that time, live media could only have a read-only root file system and was not as feature-rich as live media is today. However, just before Revisor came to life, two applications were developed; pungi for creating installation media, and livecd-tools for creating live media. These two applications did their work well; The media composed for a release, including many different custom live media spins were, and still are, created with these tools. Immediately, the Revisor developers set themselves a target to provide a single interface to both of those tools. + </para> + </section> + +</chapter> diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Plugins.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Plugins.xml new file mode 100644 index 0000000..122f25e --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Plugins.xml @@ -0,0 +1,131 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Plugins"> + <title>Plugins</title> + <para> + para + </para> + + <section id="Revisor_Reference_Manual-Plugins-Upstream"> + <title>Upstream Plugins</title> + <para> + Plugins available from upstream, maintained by upstream + </para> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Cobbler_Plugin"> + <title>Cobbler Plugin</title> + <para> + The Cobbler plugin is able to put the product composed into a Cobbler environment, by handing off the built product to the existing Cobbler infrastructure as a <emphasis>distro</emphasis>, and creating a <emphasis>profile</emphasis>. + </para> + <para> + Using this module, one can automatically import the Revisor product into a Cobbler environment, and immediately use the new Cobbler <emphasis>profile</emphasis> to start deploying or automated testing, maybe. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Composer_Plugin"> + <title>Composer Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Delta_Plugin"> + <title>Delta Plugin</title> + <para> + A small change to a ISO image does not require you to download the complete ISO image if you have a copy of the old ISO image. + </para> + <note> + <title>Only applicable to (...)</title> + <para> + The generation of Delta ISO images is only applicable to situations in which the ISO image does not contain SquashFS images. SquashFS images are smaller, but all SquashFS images are unique. Since the Delta principle is based on similarities, and no two SquashFS images are alike, creating a Delta on two ISO images containing SquashFS images will lead to a Delta pratically the same size as the SquashFS image. For Live Media that compresses the ext3 filesystem image into a SquashFS image, since that SquashFS image is probably over 97% of the size of the ISO image, creating Delta images for compressed Live Media does not make sense. For installation media however, most RPMs would be similar as well as (potentially) the installer images. + </para> + </note> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-GUI_Plugin"> + <title>GUI (Graphical User Interface) Plugin</title> + <para> + Yes, the Graphical User Interface for Revisor is actually a plugin. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-HUB_Plugin"> + <title>HUB Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin"> + <title>Isolinux Plugin</title> + <titleabbrev id="Isolinux_Plugin">Isolinux Plugin</titleabbrev> + <para> + The isolinux plugin adds the <literal>--isolinux-cfg</literal> command-line option to Revisor. Specify a file here, and the original <filename>isolinux.cfg</filename> that is built as part of the compose process is replaced by the <filename>isolinux.cfg</filename> specified. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Jigdo_Plugin"> + <title>Jigdo Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Mock_Plugin"> + <title>Mock Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Rebrand_Plugin"> + <title>Rebrand Plugin</title> + <para> + The rebrand plugin hooks in to Revisor at several different stages. The goal of this plugin is to ensure no trademarked packages end up on the media. Trademarked packages may include <application>fedora-logos</application>, <application>redhat-logos</application>, and so forth. + </para> + <para> + The plugin adds a <literal>--rebrand</literal> option, to which you can specify the name of your new product. When rebranding Fedora to Omega for example, specifying <literal>--rebrand Omega</literal> would be sufficient to make sure the product does not have any Fedora trademarks. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Reuse_Installer_Images_Plugin"> + <title>Reuse Installer Images Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Server_Plugin"> + <title>Server Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Virtualization_Plugin"> + <title>Virtualization Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-WUI_Plugin"> + <title>WUI (Web-based User Interface) Plugin</title> + <para> + para + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Plugins-Writing_Your_Own"> + <title>Writing Your Own Plugins</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Testing.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Testing.xml new file mode 100644 index 0000000..ea4ff00 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Testing.xml @@ -0,0 +1,173 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Testing"> + <title>Testing</title> + <para> + The following test cases describe different types of testing a new Revisor release. + </para> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases"> + <title>Simple Test Cases</title> + <para> + This section has a few simple test cases ensuring configuration shipped with Revisor works as anticipated. + </para> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_cases-Packages"> + <title>Packages</title> + <para> + Install the <application>revisor-cli</application>: + </para> + <para> + <screen># <userinput>yum --enablerepo=updates-testing install revisor</userinput></screen> + </para> + <para> + Installed are all dependencies for the Revisor CLI interface. Make sure <application>spin-kickstarts</application> is installed, a package for sample kickstarts. + </para> + <para> + Starting Revisor as follows should not show any error messages related to Revisor attempting to start up it's GUI interface: + </para> + <para> + <screen># <userinput>revisor</userinput></screen> + </para> + + <formalpara> + <title>Configuration Files</title> + <para> + The following configuration files should exist: + </para> + </formalpara> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/etc/revisor/revisor.conf</filename> + </para> + </listitem> + </itemizedlist> + </para> + <para> + Each section should have a configuration file listed as <literal>main</literal>. + </para> + <para> + And, of course, every configuration file listed in each section. In this case, the following snippet is easy enough: + </para> + <para> + <screen>$ <userinput>i=0; \ +configfiles="`grep ^main /etc/revisor/revisor.conf | \ + sed -r -e 's/^main.*=\s*(.*)/\1/g'`" + +for configfile in $configfiles; do \ + [ ! -f $file ] && i=1; \ +done; \ +echo $i</userinput></screen> + </para> + <para> + Another way to test the configuration file is to execute: + </para> + <para> + <screen>$ <userinput>revisor --list-models >/dev/null</userinput></screen> + </para> + <para> + If everything is well, since <literal>STDOUT</literal> is redirected to <filename>/dev/null</filename>, you should see no messages at all. + </para> + + </section> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases-Configuration_Files"> + <title>Configuration Files</title> + <para> + The main Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. The file lists a series of models, each having their own YUM configuration file in <filename>/etc/revisor/conf.d/</filename>. + </para> + <formalpara> + <title>Testing</title> + <para> + <itemizedlist> + <listitem> + <para> + For each model in <filename>/etc/revisor/revisor.conf</filename>, the <code>main</code> setting for that model should point to a valid file. + </para> + </listitem> + <listitem> + <para> + Each YUM configuration file should work. To verify, run the following command for each configuration file: + </para> + <para> + <screen>$ yum -c <replaceable>$file</replaceable> list kernel</screen> + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>Known Errors</title> + <para> + <itemizedlist> + <listitem> + <para> + Revisor has baseurls in YUM repositories set to <ulink url="http://localrepo" />. This URL will not be retrievable for many people, but allows the developers to quickly change mirrors. + </para> + </listitem> + <listitem> + <para> + Repositories that are unavailable at the moment of testing will throw errors Revisor can't do anything about. + </para> + </listitem> + <listitem> + <para> + If the directories <filename>revisor-yumcache/</filename> and <filename>revisor/</filename> in <filename>/var/tmp/</filename>, the default working directory, are not writeable for the user then YUM will throw permission denied errors. + </para> + <para> + Remove <filename>/var/tmp/revisor/</filename> and <filename>/var/tmp/revisor-yumcache/</filename> or run the command with root permissions. + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + </section> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases-Compose_Results"> + <title>Requirements for Compose Results</title> + <para> + Although heavily dependent on Anaconda for this part, these are still requirements + </para> + + <formalpara> + <title>ld-linux.so.2</title> + <para> + In the <filename>initrd.img</filename> of the composed product, if 32-bit, <filename>/lib/ld-linux.so.2</filename> (or any other version) should link to <filename>/lib/ld-2.9.so</filename> (or any other version). If <filename>/lib/ld-linux.so.2</filename> links to itself, the media will fail to install. + </para> + </formalpara> + <formalpara> + <title>How to test</title> + <para> + In a terminal, type the following command: + </para> + </formalpara> + <para> + <screen>$ <userinput>lsinitrd /path/to/initrd | grep ld-linux</userinput></screen> + </para> + <para> + See also: <ulink url="https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00115.…" /> + </para> + + </section> + </section> + + <section id="Revisor_Reference_Manual-Testing-Complex_Test_Cases"> + <title>Complex Test Cases</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Testing-Specific_Test_Cases"> + <title>Specific Test Cases</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tips_and_Tricks.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tips_and_Tricks.xml new file mode 100644 index 0000000..8b785ee --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tips_and_Tricks.xml @@ -0,0 +1,47 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Tips_and_Tricks"> + <title>Tips and Tricks</title> + <para> + para + </para> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-The_spin-kickstarts_Package"> + <title>The spin-kickstarts Package</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-Even_More_Debugging"> + <title>Even More Debugging</title> + <para> + something about using -x to buildinstall scripts + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-ksvalidator"> + <title>Kickstart Validator</title> + <para> + something about using -x to buildinstall scripts + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-Using_Mirrormanager_For_Mirror_Redirection"> + <title>Using Mirrormanager for Mirror Redirection</title> + <para> + Something about using Mirrormanager to redirect you to the local mirror (so you do not have to edit YUM configuration files). + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-The_localrepo_DNS_Alias"> + <title>Using The localrepo DNS Alias</title> + <para> + Something about using the localrepo DNS alias to point to your local mirror (either through real DNS or through /etc/hosts), so you do not have to edit the YUM configuration files. + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tweaking_The_Build_Process.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tweaking_The_Build_Process.xml new file mode 100644 index 0000000..4979285 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Tweaking_The_Build_Process.xml @@ -0,0 +1,40 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Tweaking_The_Build_Process"> + <title>Tweaking the build process</title> + <para> + para + </para> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Reusing_Existing_Installer_Images"> + <title>Reusing Existing Installer Images</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Building_The_Installer_Images_In_Mock"> + <title>Building The Installer Images in Mock</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Omitting-isomd5sum"> + <title>Omitting isomd5sums</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Omitting-sha1sums"> + <title>Omitting SHA1SUMS</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Using_Kickstart.xml b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Using_Kickstart.xml new file mode 100644 index 0000000..f3e6ab2 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Reference_Manual-Using_Kickstart.xml @@ -0,0 +1,118 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Using_Kickstart"> + <title>Using Kickstart</title> + <para> + Kickstart is a configuration file format for automating installation procedures. Or at least, it was, originally. Nowadays, kickstart files are used as input to the compose tools, including Revisor. + </para> + <para> + Revisor again is unique in that it does not require a kickstart file for input. The other tools only take kickstart configuration files. Revisor though allows most of what is in a kickstart file to be configured interactively in Graphical User Interface mode. + </para> + + <section id="Revisor_Reference_Manual-Using_Kickstart-How_Kickstart_Is_Used"> + <title>How Kickstart Is Used</title> + <para> + There's two cases in which a kickstart file is used differently. One is during the compose of installation media, and the other of course is during the compose of live media, or virtualization media. + </para> + + <section id="Revisor_Reference_Manual-Using_Kickstart-How_Kickstart_Is_Used-Installation_Media"> + <title>Installation Media</title> + <para> + In the case of installation media, the following settings are used: + </para> + <para> + <itemizedlist> + <listitem> + <formalpara> + <title><literal>repo</literal></title> + <para> + The <literal>repo</literal> command in kickstart is used when Revisor is configured to use the repositories configured in the kickstart file only. Use <literal>kickstart_repos = 1</literal> to enable this feature, or set the appropriate checkbox in the Revisor GUI. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><literal>%packages</literal></title> + <para> + The <literal>%packages</literal> section in kickstart is used to determine the RPM payload on the installation media. It can include groups and packages, and exclude packages. It accepts wildcards, both in includes and excludes of packages (but not groups). + </para> + </formalpara> + </listitem> + </itemizedlist> + </para> + <note> + <title>@core and @base</title> + <para> + By default, groups @core and @base are included in the package manifest. You can specify @base to not be included, by using <literal>%packages --nobase</literal>, but @core cannot be excluded using a kickstart package manifest. + </para> + </note> + <para> + Using <literal>kickstart_exact</literal>, you can exclude @core and @base so that you need to explicitly select them in the kickstart package manifest. + </para> + <para> + Using <literal>kickstart_exact_nevra</literal> ... + </para> + </section> + </section> + + <section id="Revisor_Reference_Manual-Using_Kickstart-The_Kickstart_Package_Manifest"> + <title>The Kickstart Package Manifest</title> + <para> + para + </para> + + <formalpara> + <title>Group @core</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Group @base</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Including groups of packages</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Including a single package</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Excluding a single package</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Using wildcard matches</title> + <para> + para + </para> + </formalpara> + + <section id="Revisor_Reference_Manual-Using_Kickstart-Using_Kickstart_With_Package_NEVRA"> + <title>Using Kickstart with Package NEVRA</title> + <para> + para + </para> + </section> + + </section> + +</chapter> + commit 366d7b924df14b119f627ddeda435ca2d32c3099 Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Thu Jun 18 16:01:38 2009 +0200 Update more and more diff --git a/doc/Reference_Manual/en-US/Appendix.xml b/doc/Reference_Manual/en-US/Appendix.xml index 01258fb..f08fc79 100644 --- a/doc/Reference_Manual/en-US/Appendix.xml +++ b/doc/Reference_Manual/en-US/Appendix.xml @@ -2,12 +2,12 @@ <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> -<part id="Revisor_Documentation-Appendices"> +<part id="Revisor_Reference_Manual-Appendices"> <title>Appendices</title> - <appendix id="Revisor_Documentation-Appendix-Terminology" label="A"> + <appendix id="Revisor_Reference_Manual-Appendix-Terminology" label="A"> <title>Terminology</title> - <formalpara id="Revisor_Documentation-Appendix-Terminology-model"> + <formalpara id="Revisor_Reference_Manual-Appendix-Terminology-model"> <title>Model</title> <indexterm> <primary>model</primary> @@ -17,7 +17,7 @@ </para> </formalpara> - <formalpara id="Revisor_Documentation-Appendix-Terminology-package_manifest"> + <formalpara id="Revisor_Reference_Manual-Appendix-Terminology-package_manifest"> <title>Package Manifest</title> <indexterm> <primary>Package Manifest</primary> @@ -27,7 +27,7 @@ </para> </formalpara> - <formalpara id="Revisor_Documentation-Appendix-Terminology-Remix"> + <formalpara id="Revisor_Reference_Manual-Appendix-Terminology-Remix"> <title>Remix</title> <indexterm> <primary>Remix</primary> @@ -37,7 +37,7 @@ </para> </formalpara> - <formalpara id="Revisor_Documentation-Appendix-Terminology-Re-Spin"> + <formalpara id="Revisor_Reference_Manual-Appendix-Terminology-Re-Spin"> <title>Re-Spin</title> <indexterm> <primary>Re-Spin</primary> @@ -51,7 +51,7 @@ Fedora Unity releases Fedora Re-Spins every so often, twice or trice per release. </para> - <formalpara id="Revisor_Documentation-Appendix-Terminology-Spin"> + <formalpara id="Revisor_Reference_Manual-Appendix-Terminology-Spin"> <title>Spin</title> <indexterm> <primary>Spin</primary> @@ -64,7 +64,7 @@ Fedora Spins have gone through the Spins Process (<ulink url="http://fedoraproject.org/wiki/Spins_Process" />), and have been approved trademark usage by the Fedora Project Board. </para> - <formalpara id="Revisor_Documentation-Appendix-Terminology-Package_Sack"> + <formalpara id="Revisor_Reference_Manual-Appendix-Terminology-Package_Sack"> <title>Package Sack</title> <indexterm> <primary>Package Sack</primary> @@ -75,13 +75,13 @@ </formalpara> </appendix> - <appendix id="Revisor_Documentation-Appendix-Configuration_Reference" label="B"> + <appendix id="Revisor_Reference_Manual-Appendix-Configuration_Reference" label="B"> <title>Configuration Reference</title> <para> This is the configuration reference for Revisor. Options are listed in alphabetical order. </para> - <section id="Revisor_Documentation-Appendix-Configuration_Reference-Media_Options"> + <section id="Revisor_Reference_Manual-Appendix-Configuration_Reference-Media_Options"> <title>Configuration Options</title> <para> <table> @@ -213,7 +213,7 @@ <entry>global, model</entry> </row> <row> - <entry namest="column25" nameend="column89">Whether to include the relatively large boot.iso on the optical installation media created. Setting this to 0 will still include boot.iso in the installation tree created (if configured with <code>media_installation_tree</code><footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Documentation-Compose_Process_Details" /> for more details.</para></footnote>)</entry> + <entry namest="column25" nameend="column89">Whether to include the relatively large boot.iso on the optical installation media created. Setting this to 0 will still include boot.iso in the installation tree created (if configured with <code>media_installation_tree</code><footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Reference_Manual-Compose_Process_Details" /> for more details.</para></footnote>)</entry> </row> <row> @@ -382,7 +382,7 @@ <entry>global, model</entry> </row> <row> - <entry namest="column25" nameend="column89">Whether to create a an installation tree<footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Documentation-Compose_Process_Details" /> for more details.</para></footnote> (for publication over HTTP or FTP, or through Cobbler). No size limit.</entry> + <entry namest="column25" nameend="column89">Whether to create a an installation tree<footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Reference_Manual-Compose_Process_Details" /> for more details.</para></footnote> (for publication over HTTP or FTP, or through Cobbler). No size limit.</entry> </row> <row> @@ -447,7 +447,7 @@ <entry>global, model</entry> </row> <row> - <entry namest="column25" nameend="column89">Whether Revisor should operate in <emphasis>respin</emphasis> mode. See also <xref linkend="Revisor_Documentation-Compose_Process_Details-Respin_Mode" /></entry> + <entry namest="column25" nameend="column89">Whether Revisor should operate in <emphasis>respin</emphasis> mode. See also <xref linkend="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode" /></entry> </row> <row> diff --git a/doc/Reference_Manual/en-US/Book_Info.xml b/doc/Reference_Manual/en-US/Book_Info.xml index 0b84805..31d0e76 100644 --- a/doc/Reference_Manual/en-US/Book_Info.xml +++ b/doc/Reference_Manual/en-US/Book_Info.xml @@ -2,7 +2,7 @@ <!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> -<bookinfo id="Revisor_Documentation-Documentation"> +<bookinfo id="Revisor_Reference_Manual-Documentation"> <title>Reference Manual</title> <subtitle>Revisor Complete Installation, Configuration and Tweaking Reference</subtitle> <productname>Revisor</productname> diff --git a/doc/Reference_Manual/en-US/Preface.xml b/doc/Reference_Manual/en-US/Preface.xml index 02af0ea..0623129 100644 --- a/doc/Reference_Manual/en-US/Preface.xml +++ b/doc/Reference_Manual/en-US/Preface.xml @@ -2,13 +2,13 @@ <!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> -<preface id="Revisor_Documentation-Preface"> +<preface id="Revisor_Reference_Manual-Preface"> <title>Preface</title> <para> This is the documentation for Revisor, a utility to create and customize your own Linux distribution based on Fedora, Red Hat Enterprise Linux or CentOS. </para> - <section id="Revisor_Documentation-Preface-About_The_Contributors"> + <section id="Revisor_Reference_Manual-Preface-About_The_Contributors"> <title>About the Contributors</title> <formalpara> <title>Author</title> @@ -28,7 +28,7 @@ </formalpara> </section> - <section id="Revisor_Documentation-Preface-About_Fedora_Unity"> + <section id="Revisor_Reference_Manual-Preface-About_Fedora_Unity"> <title>About Fedora Unity</title> <para> The Fedora Unity Project consists of a group of concerned peers from within the Fedora community that strive to bring the best possible solutions to the community, in a consistent manner. This, amongst other things, resulted in extensive documentation on various topics often referred to on the Web, published under the Open Documentation License v1.0. @@ -38,10 +38,10 @@ </para> </section> - <section id="Revisor_Documentation-Preface-About_This_Document"> + <section id="Revisor_Reference_Manual-Preface-About_This_Document"> <title>About this Document</title> <para> - This document is licensed under the Open Publication License version 1.0, which is available at <ulink url="http://www.opencontent.org/openpub/" />. You can get the latest version from <ulink url="http://kanarip.fedorapeople.org/Revisor_Documentation/en-US/pdf/Revisor_Doc…" /> (PDF), and it's sources live at <ulink url="http://git.fedorahosted.org/git/?p=revisor;a=tree;f=doc" />. + This document is licensed under the Open Publication License version 1.0, which is available at <ulink url="http://www.opencontent.org/openpub/" />. You can get the latest version from <ulink url="http://kanarip.fedorapeople.org/Revisor_Reference_Manual/en-US/pdf/Revisor_…" /> (PDF), and it's sources live at <ulink url="http://git.fedorahosted.org/git/?p=revisor;a=tree;f=doc" />. </para> </section> diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Compose_Process_Details.xml b/doc/Reference_Manual/en-US/Reference_Manual-Compose_Process_Details.xml new file mode 100644 index 0000000..6b12e6c --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Compose_Process_Details.xml @@ -0,0 +1,431 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Compose_Process_Details"> + <title>Compose Process Details</title> + <para> + This chapter lists the details of the compose process as well as dives deep into the features of Revisor. + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Overview"> + <title>Overview</title> + <titleabbrev id="Compose_Process_Details-Overview">Overview</titleabbrev> + <para> + Of course, the compose process for installation media is a little different then the compose process for live media. + </para> + <para> + When composing, Revisor starts out doing the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Revisor initiates and loads plugins, options, and defaults. At this point, Revisor has a so-called <emphasis>ConfigStore</emphasis> that holds all options Revisor knows about. + </para> + </listitem> + <listitem> + <para> + Revisor reads the options from the command-line. + </para> + </listitem> + <listitem> + <para> + Revisor reads the configuration file specified with the <code>--config</code> command-line parameter, or uses it's builtin default, <filename>/etc/revisor/revisor.conf</filename>. + </para> + </listitem> + <listitem> + <para> + Revisor reads the global <code>[revisor]</code> section for all settings available in it's <emphasis>ConfigStore</emphasis> and sets those configured in the global section. Remember that if an option is not available in the <emphasis>ConfigStore</emphasis> but is configured in the global configuration section, it is ignored. + </para> + </listitem> + <listitem> + <para> + If a model is specified in the configuration file's global section <code>[revisor]</code>, Revisor will set that model to be used and loads it. + </para> + </listitem> + <listitem> + <para> + If a model has been specified on the command-line, with option <code>--model</code>, Revisor loads that model. + </para> + </listitem> + <listitem> + <para> + When loading the model, Revisor again iterates over all the settings that are in the <emphasis>ConfigStore</emphasis>, checks if the setting has been configured in the model section, and adjusts the setting in the <emphasis>ConfigStore</emphasis> if necessary. Again remember that if the <emphasis>ConfigStore</emphasis> does not know about one or the other option already, that setting is ignored. + </para> + </listitem> + <listitem> + <para> + Now that the defaults and configuration file settings have been applied to the <emphasis>ConfigStore</emphasis>, it is time for Revisor to look at the options specified on the command-line to see if you wanted to override anything. + </para> + </listitem> + <listitem> + <para> + While loading each configuration setting available in the global <code>[revisor]</code>, model-specific sections and/or command-line, Revisor checks every settings against a function that is specifically written to check such setting. For example, the label of an ISO cannot be longer then 32 characters. + </para> + </listitem> + <listitem> + <para> + Especially in CLI mode, these settings build up the task list for Revisor. If there's nothing to do, Revisor will throw an error explaining what's missing. If there's things to do that cannot be done in one run, Revisor will throw an error explaining that. + </para> + </listitem> + <listitem> + <para> + In Graphical User Interface mode however, if the settings loaded so far are all OK, the GUI will start. Since you can still adjust a few settings from within the GUI, the settings loaded so far will be the defaults for configuration settings that have a dialog for you to adjust them with, throughout the rest of the process. + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Installation_Media"> + <title>Installation Media</title> + <para> + As we've explained before, composing installation media is a little different then composing live media. That's not just because installation media should start an installation procedure and live media should show you a nice, shiny, fully-functional Desktop. + </para> + <para> + For one, installation media allows split media. This means that Revisor can span the payload of the product over multiple ISO images or multiple discs, if you will. When composing installation media, Revisor basically does the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Of course, Revisor goes through the loading of configuration options mentioned in the <xref linkend="Revisor_Reference_Manual-Compose_Process_Details-Overview" endterm="Compose_Process_Details-Overview" />. + </para> + </listitem> + <listitem> + <para> + When you're done specifying options in the GUI, or when Revisor thinks it can go ahead using the options specified in CLI mode, it takes the list of packages selected from either the GUI or the kickstart <code>%packages</code> manifest. + </para> + <para> + Not getting too deep into details here, yet, because some of these things are routines shared with other composing modes, but here's a few additional considerations Revisor makes when doing the package selection. + </para> + <para> + <itemizedlist> + <listitem> + <para> + Normally, a kickstart <code>%packages</code> manifest only allows you to select package <emphasis>names</emphasis>. With Revisor though, you can select exact package <emphasis>NEVRA</emphasis> to select a certain version or architecture for the package that you want. Additionally, if a package is not available, Revisor searches the <emphasis>Provides</emphasis> of the available packages. + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Live_Media"> + <title>Live Media</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode"> + <title>Respin Mode</title> + <para> + Revisor has a respin mode that in some aspects differs from the regular routines. It is intended to reflect behaviour of tools in use by the Fedora Project Release Engineering team as closely as possible. + </para> + <para> + Re-Spin mode only affects installation media products. + </para> + <para> + In Re-Spin mode, the way the RPM payload is determined from kickstart differs from Revisor's normal procedures. See <xref linkend="Revisor_Reference_Manual-Using_Kickstart" /> for more details on using a kickstart package manifest. + </para> + <para> + A kickstart file's so-called <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-package_manifest" /> usually looks like: + </para> + <para> + <screen>%packages +@group1 +@group2 --nodefaults +@group3 --optional +package1 +package2 +-package3 +%end</screen> + </para> + <para> + Which tells us the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Include all mandatory and default packages from group1 + </para> + </listitem> + <listitem> + <para> + Include all mandatory packages from group2 + </para> + </listitem> + <listitem> + <para> + Include all mandatory, default and optional packages from group3 + </para> + </listitem> + <listitem> + <para> + Include package1, and package2 + </para> + </listitem> + <listitem> + <para> + Exclude package3 + </para> + </listitem> + </itemizedlist> + </para> + <para> + Depending on how you use this instructions or information, there is a slight difference in the package set that ends up on the media you compose. + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode-Selecting_Groups"> + <title>Selecting Groups</title> + <para> + Selecting groups has the following logic: When you load a repository you may also load the groups file (often referred to as 'comps' or 'comps.xml'). This comps file is an XML file with categories, groups (per category), and per group: + </para> + <para> + <itemizedlist> + <listitem> + <para> + a list of mandatory packages. If you select or include the group, these packages come with it. + </para> + </listitem> + <listitem> + <para> + a list of default packages. If you select or include the group, these packages will come with it as a default. If you only want the mandatory, minimum set of packages for this group, in a kickstart package manifest append <code>--nodefaults</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Deselect all packages</emphasis>. + </para> + </listitem> + <listitem> + <para> + a list of optional packages. If you select a group you have not yet selected these packages. To select the optional packages of a group, in a kickstart package manifest append <code>--optional</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Select all optional packages</emphasis>. + </para> + </listitem> + <listitem> + <para> + a list of conditionals. If you select this group, these conditionals are thrown into the package sack and transaction information and include or exclude other packages. Suppose you select the '@nl-support' or “Dutch Support” group from the Languages or Localization category, you would end up with support for the Dutch language in all applications that have that kind of support. + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Respin_Mode-Select_Matching_Packages"> + <title>Select Matching Packages</title> + <para> + This is the logic Revisor applies when running in Re-Spin mode (on the CLI, specify <code>--respin</code>). It imitates the behavior pungi has, and thus enables you to copy that behavior. Note that <code>--respin</code> has other implications as well. + </para> + <para> + First of all, it iterates the groups in the kickstart package manifest. For each group, it appends the names of the mandatory packages to a list, and depending on the additional parameters specified with that group (<code>--nodefaults</code> or <code>--optional</code>), appends the names of the other packages in that group as well. + </para> + <para> + Then it iterates over the package names in the package manifest. These package names are appended to the same list of package names too. This includes package 'names' with some sort of wildcard (?, or *). + </para> + <para> + Then it iterates over all the excluded packages, appending each of those to the YUM configuration exclude list. + </para> + <para> + Now that Revisor has a very simple, flat list of package names, it uses YUM's internal matching logic 5 to get what packages in the repositories matched exactly (by name), matched (by wildcard) and did not match at all. Revisor then selects the exact matches and matches, adding them to the transaction. + </para> + </section> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving"> + <title>Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + </indexterm> + <para> + Dependency resolving is the area where some of the efficiency Revisor can gain for you comes from. While of course there is specific reasons to do things one way, or the other, most people I speak to about Revisor, it is not very clear why, or what Revisor does in this area. First of all, there's two ways of resolving dependencies: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Inclusive Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + <secondary>Inclusive</secondary> + </indexterm> + <para> + Iterate all packages in the transaction and list their requirements, then for each of those requirements, find all packages that provide a matching capability, add those packages to the transaction, and don't forget to add the requirements those packages have themselves, back into the pile of (unmet) requirements. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Exclusive Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + <secondary>Inclusive</secondary> + </indexterm> + <para> + Iterate all the packages and for each of the requirements found, find the best package that meets the requirement. This is also YUMs default behavior. Anaconda uses YUM during the installation, and this is the behaviour of YUM used during the installation. + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive"> + <title>Inclusive Dependency Resolving</title> + <para> + Hypothetically, you could describe inclusive dependency as follows: + </para> + <para> + <screen>final_packages = [] +more_to_do = True +while more_to_do: +more_to_do = False +for package in packages: + if package in final_packages: + continue + + dependencies = find_package_dependencies() + for dependency in dependencies: + pulled_in_package = pull_in_dependency() + if pulled_in_package not in final_packages: + packages.append(pulled_in_package) + more_to_do = True</screen> + </para> + <para> + So, what does this mean? Basically, it means that if there is a requirement for a capability, all packages providing that capability are being pulled in. Now imagine package 'foo' requires capability 'web-client'. There's a number of packages providing that capability, right? So you get Firefox, lynx, elinks, konqueror, safari, Netscape, Internet Explorer, emacs, for free! All of those pull in their own dependencies also, of course. + </para> + <note> + <para> + If you catch this before it catches you, you can prevent the packages from being pulled in during dependency resolving by not making the package available in the <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-Package_Sack" /> in the first place, using the <literal>-firefox</literal> syntax in the kickstart package manifest, and setting <literal>kickstart_uses_pkgsack_excludes</literal> to 1. + </para> + </note> + <note> + <para> + You may have thought of it; pulling in packages this way may give you a package set (or <emphasis>RPM payload</emphasis>) that has conflicting packages. Imagine package <application>foo</application> requiring capability <application>bar</application>, which is provided by two packages that conflict with one another (either on explicit <literal>Conflicts:</literal> RPM header or file level). Both will be pulled in, hence disabling you to install everything (<literal>'*'</literal> or -previously- <literal>@Everything</literal> in the kickstart package manifest). + </para> + </note> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Makes_Sense"> + <title>When This Makes Sense</title> + <para> + If you are composing a large distribution of which 3 million users in even so many different situations having so many different expectations and desires, you will want this behaviour, since you won't be able to determine which one of the packages for each capability someone in that group wants, and which one may not want. Or, in case of upgrades, what the system needs. Shipping them all on the same media is the best solution in these cases. + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Does_Not_Make_Sense"> + <title>When This Does Not Make Sense</title> + <para> + <itemizedlist> + <listitem> + <para> + When creating installation media to be installed unattended, or to be used in conjunction with deployment strategies + </para> + </listitem> + <listitem> + <para> + When creating installation media to be upgrading PCs you have controlled from the beginning, such as in a company + </para> + </listitem> + <listitem> + <para> + Installation for a small group of users or systems + </para> + </listitem> + <listitem> + <para> + When creating minimal installation media, or media with a minimal RPM payload. + </para> + </listitem> + <listitem> + <para> + When creating installation media that is to be used with installing "Everything" in the RPM payload. + </para> + </listitem> + </itemizedlist> + </para> + </section> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Dependency_Resolving-Exclusive"> + <title>Exclusive Dependency Resolving</title> + <para> + Exclusive dependency resolving is what YUM does when you execute a <application>yum install</application>. Unless you've specified one of the packages satisfying any of the dependencies in the transaction, YUM is going to look up the best match for you. This results in the installation of only one package providing the requirement(s) of other packages, rather then all packages providing said requirement being installed. + </para> + <para> + As an example, imagine you install a package foo which requires capability web-client. Using exclusive dependency resolving, YUM would select one package providing the web-client capability whereas inclusive dependency resolving would include all packages providing the web-client capability. + </para> + <para> + During the installation procedure, one of the major features of installation media, anaconda is going to use YUM dependency resolving to satisfy all the dependencies. + </para> + <note> + <title>Installation Procedure !== Upgrade Procedure</title> + <para> + Note that an installation procedure is not the same as an upgrade procedure. With an installation procedure for example, you have control over the partitioning layout whereas with an upgrade procedure, you have none. More importantly, during an upgrade procedure, the (already installed) system has an existing package set which needs to be updated/upgraded and thus could possibly introduce dependency resolving problems, because of third party packages installed on the system, or because the media used to upgrade the system with does not contain the software packages needed to complete the upgrade RPM transaction. + </para> + </note> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Copying_Arbitrary_Files_Onto_The_Media"> + <title>Copying Arbitrary Files Onto the Media</title> + <para> + With <literal>--copy-dir</literal>, you can specify a path Revisor should copy onto the media. + </para> + <formalpara> + <title>Installation Media</title> + <para> + In the case of installation media, the path specified with <literal>--copy-dir</literal> will be copied recursively to the <filename>files/</filename> sub-directory at the root of the ISO image (or the first ISO image if you compose split media). + </para> + </formalpara> + <para> + A few use-case examples: + </para> + <para> + <itemizedlist> + <listitem> + <para> + If one kickstart profile is not enough for you to deploy the product onto your systems, create a directory that holds multiple kickstart files and specify the path to that directory using <literal>--copy-dir</literal>. The kickstart files now end up available to the installation procedures as <filename>cdrom:/files/*.ks</filename>, and can thus be used by specifying them on the kernel cmdline (<code>ks=cdrom:/files/profile1.ks</code>), or, when used in combination with <literal>--isolinux-cfg</literal> from the <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin" endterm="Isolinux_Plugin" />, can be added as an option in the isolinux menu. + </para> + </listitem> + <listitem> + <para> + If you have files or scripts that need to be copied onto, or run on, the installed system before it attempts to reboot and operate normally, you can use <literal>--copy-dir</literal> to make these files and scripts available during the installation and copy or execute them from either <code>%pre</code> or <code>%post</code> scripts. + </para> + </listitem> + </itemizedlist> + </para> + <formalpara> + <title>Live Media</title> + <para> + In the case of live media, the path specified with <literal>--copy-dir</literal> will be copied recursively onto the root directory (<filename>/</filename>) of the live media filesystem (which is probably loop-mounted onto <filename>/var/tmp/revisor/</filename>). + </para> + </formalpara> + <para> + If, for example, you want to copy a home directory onto the live media, and the home directory you want to copy is at <filename>/home/user1/</filename> on the composing system, you copy this directory so that the root of that new directory has a sub-directory <filename>home/</filename> which in turn contains a sub-directory <filename>user1/</filename>: + </para> + <para> + <screen>$ <userinput>mkdir -p /tmp/something/home/</userinput> +$ <userinput>cp -a /home/user1 /tmp/something/home/.</userinput> +$ <userinput>revisor [options] --copy-dir /tmp/something/</userinput></screen> + </para> + </section> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Cleaning_Up"> + <title>Cleaning Up</title> + <para> + Revisor tends to clean up after itself by default. If a product compose succeeds, you (probably) don't need to change this default behaviour. However, by default, Revisor tends to leave the YUM cache directories untouched. This is to prevent you from having to download all the packages a second, third or more times when you run another compose. + </para> + <para> + To change this default behaviour, Revisor has an option <literal>--clean-up</literal>. The default value for this option is <literal>1</literal>, meaning Revisor will clean up it's temporary, compose-specific files, but no files that could be re-used. Specifying <literal>--clean-up=0</literal> will cause Revisor to leave everything behind and not clean anything up at all. This is most ideal for troubleshooting purposes, where one needs to examine the temporary, compose-specific files and see what went wrong. To clean up everything however, because for example you might be low on disk-space, use <literal>--clean-up=2</literal>. Revisor will then also clean up the files that could be re-used. + </para> + + <section id="Revisor_Reference_Manual-Compose_Process_Details-Cleaning_Up-Exception-to-the-Rule"> + <title>Exception to the Rule</title> + <para> + There's one exception to the rule of cleaning up. <filename>/var/tmp/revisor/</filename>, or put more accurately, the path specified as the <code>installroot</code> in the YUM configuration file configured with the model used to compose the product, will not be cleaned up afterwards. When composing live media, this directory may still be in use as a mount-point for the live media filesystem. Removing this directory recursively in these cases would not make sense. + </para> + </section> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Configuration.xml b/doc/Reference_Manual/en-US/Reference_Manual-Configuration.xml new file mode 100644 index 0000000..647706f --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Configuration.xml @@ -0,0 +1,280 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Configuration"> + <title>Configuration</title> + <para> + Revisor configuration can be performed using <xref linkend="Revisor_Reference_Manual-Configuration-Files" />, or through <xref linkend="Revisor_Reference_Manual-Configuration-Command-line_Options" />. + </para> + + <section id="Revisor_Reference_Manual-Configuration-Files"> + <title>Configuration Files</title> + <para> + Revisor uses configuration files for a large part of it's operations. These files mostly reside in <filename>/etc/revisor/</filename>. There is two types of files Revisor uses: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Revisor Configuration Files</title> + <para> + Revisor configuration files, such as <filename>/etc/revisor/revisor.conf</filename>, contain information and settings unique to Revisor. A Revisor configuration file is where you specify default options, and include information on different products you want to compose. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>YUM Configuration Files</title> + <para> + YUM configuration files, such as the files in <filename>/etc/revisor/conf.d/</filename>, contain configuration for YUM. To be more precise, Revisor doesn't even handle the files (it let's YUM do so). The files in <filename>/etc/revisor/conf.d/</filename> practically contain the same information as <filename>/etc/yum.conf</filename> combined with the files in <filename>/etc/yum.repos.d/</filename> (but not exactly the same content!). + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + + <section id="Revisor_Reference_Manual-Configuration-Files-_etc_revisor_revisor.conf"> + <title><filename>/etc/revisor/revisor.conf</filename></title> + <para> + The default Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. This configuration file contains two sections: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title><literal>[revisor]</literal></title> + <para> + The global section. Options specified in this section apply to all the models defined in this configuration file. + </para> + </formalpara> + <para> + See also: <xref linkend="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration" /> + </para> + </listitem> + <listitem> + <formalpara> + <title><literal>[<replaceable>model</replaceable>]</literal></title> + <para> + Model configuration. One section per <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-model" />. + </para> + </formalpara> + <para> + See also: <xref linkend="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration" /> + </para> + </listitem> + </orderedlist> + </para> + <para> + Model sections basically define a single product. Amongst other things, the distribution name, release version, architecture for the product to be composed and what YUM configuration file to use, are (often) defined on a per-model basis. There is a large number of settings available for models, and they are all related to how the product is going to look like. The product name, the location of the RPM payload for installation media, the ISO label, the YUM configuration file to use, are all model settings. + </para> + <para> + Using models, you can reproduce the outcome of the compose process, a <emphasis>product</emphasis>, simply by not changing the model configuration anymore. If you want something different, you can just add another model section, and name it differently. + </para> + <para> + To see what models are available with the Revisor standard package, use: + </para> + <para> + <screen>$ <userinput>revisor --list-models</userinput></screen> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Files-_etc_revisor_conf.d_"> + <title><filename>/etc/revisor/conf.d/</filename></title> + <para> + The default YUM configuration files used by Revisor. In a model configuration section, the <literal>main =</literal> setting points to one of the YUM configuration files in <filename>/etc/revisor/conf.d/</filename> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Files-Updates"> + <title>Updates to Configuration Files</title> + <para> + The Revisor packages are not allowed to overwrite files in <filename>/etc/</filename>, and they should thus not do so. If an update to Revisor is installed on your system, files with the extension <literal>.rpmnew</literal> may be created --if you had changed anything in the file before applying the update. Since this world isn't perfect, configuration errors may exist in the configuration files shipped with Revisor. Please pay close attention to updates to these configuration files by examining the <literal>.rpmnew</literal> files. + </para> + <para> + You can use any file location (not just <filename>/etc/revisor/</filename>) for your own custom configuration. + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Files-Changing_Configuration_Files"> + <title>Changing Configuration Files</title> + <para> + If you are creating your own models off of the ones that ship with Revisor itself, please consider using an alternative configuration file (a file other then <filename>/etc/revisor/revisor.conf</filename>, or copy the original file for safekeeping. This way, you can always return to a working, sample configuration file and test whether it is Revisor causing errors, or configuration mistakes. + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Configuration-Global_and_Model_Configuration"> + <title>Global and Model Configuration</title> + <para> + The default Revisor configuration file, <filename>/etc/revisor/revisor.conf</filename> consists of multiple sections (the file is in .INI format). One is the <literal>[revisor]</literal> global section, where you specify configuration options that apply to each other section or <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-model" />. + </para> + <para> + The options specified in the global and model configuration sections apply to the Revisor compose in the following order: + </para> + <para> + <orderedlist> + <listitem> + <para> + The options from the global section are read, tested and set. + </para> + </listitem> + <listitem> + <para> + The options from a model section are read, tested and set, regardless of whether the global section had caused the setting to be set to a certain value already. + </para> + </listitem> + </orderedlist> + </para> + <para> + For example, if you know all the models in a configuration file are optical live media products, the configuration sections could look like the following: + </para> + <para> + <screen>[revisor] +# Optical live media for all models +media_live_optical = 1 + +[model1] +main = /etc/revisor/conf.d/revisor-model1.conf +description = The model1 product +architecture = i386 +# This is already configured in the global section of +# this configuration file and can thus be removed. +#media_live_optical = 1</screen> + </para> + <note> + <title>When Running the GUI</title> + <para> + Note that when running Revisor in Graphical User Interface mode, you can still change a lot of the settings supplied by Revisor through the configuration files loaded. When you are running Revisor in GUI mode, the configuration files supply the defaults. + </para> + </note> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories"> + <title>YUM Repository Configuration</title> + <para> + The files in <filename>/etc/revisor/conf.d/</filename> are YUM configuration files. Revisor directs YUM to use these files during the compose process, and does not handle these files itself. This chapter lists a few tips and tricks. + </para> + <para> + Because these files are YUM Configuration files, you can configure anything that YUM supports. See <application>man yum.conf</application> for more details. + </para> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-releasever_and_basearch"> + <title>$releasever and $basearch</title> + <para> + When configuring a repository URL, make sure you do not use <replaceable>$releasever</replaceable> or <replaceable>$basearch</replaceable> variables. Since Revisor allows cross-composing distributions between different versions of the operating system, as well as different architectures, these variables need to be expanded to the value intended. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_a_Local_Mirror"> + <title>Using a Local Mirror</title> + <para> + If you have a local mirror of Fedora, you can use the <literal>baseurl</literal> configuration directive in each repository configuration section to tell YUM to use the local mirror. + </para> + <para> + Optionally, you can also disable the <literal>mirrorlist</literal>, preferably by outcommenting it, so that YUM will only use the local mirror. + </para> + <para> + The default <literal>baseurl</literal> uses <literal>http://download.fedoraproject.org/</literal>. This location may or may not be suitable for you. If you have a local mirror, you might want to change this setting here, or add your mirror to Fedora Project's Mirrorlist. + </para> + <note> + <title>Adding your local mirror to the Mirrorlist</title> + <para> + You can add your local mirror to the Mirrorlist, so that the Fedora Project mirrorlist redirects you to your local mirror. Additionally, systems in your local network(s) will be redirected to the local mirror. The local mirror does not have to be a public mirror in order to do so. See <ulink url="http://admin.fedoraproject.org/mirrormanager/" /> for more details. + </para> + </note> + <para> + Set each <literal>baseurl</literal> to the location of the repository on the local mirror. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_Local_Files"> + <title>Using Local Files</title> + <para> + If you have the repositories on your local filesystem, configure a <literal>baseurl</literal> of <filename>file://<replaceable>/path/to/repository/</replaceable></filename>. + </para> + <note> + <title>Make sure to supply the correct path</title> + <para> + Make sure to supply the correct path to the repository. <filename>file://</filename> is the "<emphasis>protocol</emphasis>" for the location, and the location is <filename><replaceable>/path/to/repository/</replaceable></filename>. Put together, you have <emphasis>three</emphasis> slashes. + </para> + </note> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Using_a_DVD"> + <title>Using a DVD</title> + <para> + A DVD does not contain enough packages to rebuild the installer images. If you are using a DVD and you want to rebuild the installer images, you will need to have a network connection and a mirror you can reach. + </para> + <para> + There is a list of required packages, but since the packages change per release and may change in the middle of the release cycle as well, we cannot hand you a list that just works. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Adding_Third_Party_Repositories"> + <title>Adding Third Party Repositories</title> + <para> + When adding a third party repository, make sure you add the correct release version as well as architecture to the Revisor YUM configuration file. Verify the location for the <literal>baseurl</literal> and/or <literal>mirrorlist</literal> you configure manually or through YUM. Make sure you expand any <literal>$releasever</literal>, <literal>$basearch</literal> and <literal>$arch</literal> variables. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Creating_Your_Own_Repository"> + <title>Creating Your Own Repository</title> + <para> + Creating your own repository is relatively simple. You take a directory, dump some RPM packages in it, and run <application>createrepo</application>. See <literal>man createrepo</literal> for more information. + </para> + <para> + People often wonder how Revisor handles comps.xml group files. + </para> + <para> + When you create your own repository, follow the directions in <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Adding_Third_Party_Repositories" /> to add the repository configuration to Revisor's YUM configuration, since your own repository is a third party repository as well. + </para> + <para> + See also <xref linkend="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Yum_Repositories-Troubleshooting"> + <title>Testing & Troubleshooting the YUM Configuration</title> + <para> + Before you use the (modified) configuration file, take it for a test run. + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Configuration-Configuring_A_Proxy"> + <title>Configuring A Proxy Server</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Configuration-Command-line_Options"> + <title>Command-line Options</title> + <para> + With the command-line options available, you can configure options that either override what is in the configuration file or have simply not been configured using the configuration file. With the default configuration files that come with the <application>revisor-cli</application> package for example, no media products have been pre-configured in the default section. In the <application>revisor-unity</application> package however, some default configuration has been applied so that Fedora Unity Re-Spins actually create CD, DVD and Rescue ISO images as well as the Installation Tree and include the sources. + </para> + <para> + Only some configuration options have CLI parameters. Use <application>revisor --help</application> to see a complete list of configuration options you can supply on the command line. + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Development.xml b/doc/Reference_Manual/en-US/Reference_Manual-Development.xml new file mode 100644 index 0000000..9df83c1 --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Development.xml @@ -0,0 +1,220 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Development"> + <title>Development</title> + <para> + This chapter sheds some light on development of Revisor, such as different branches and maintenance policies, versioning schemas, etcetera. + </para> + <para> + This part of the documentation relies on whether you have <application>sudo</application> set up properly. If you have not, you're on your own. + </para> + + <section id="Revisor_Reference_Manual-Development-Running_Revisor_from_Source"> + <title>Running Revisor from Source</title> + <para> + The latest code in GIT can be built into a RPM you can install but one of the advantages of having the complete source tree is that you can run it directly from that source tree so that when you pull in the next updates you do not have to rebuild the RPM. Note that we do not bump the version number for every little change we make, and as such the RPM built does not allow you to use <literal>rpm -Uvh</literal> or <literal>rpm -Uvh --oldpackage</literal>. Of course, Revisor's Makefiles also allow <application>make install</application>, but that leaves a number of unmanaged files on your computer you would have to track down manually in order to remove Revisor completely. + </para> + <warning> + <title>Cannot have Revisor RPMs installed</title> + <para> + When running revisor from within the source tree, you cannot have any of the Revisor packages installed. Having Revisor RPM packages installed regardless will mess up the GIT repository or source tree. + </para> + </warning> + <para> + To run Revisor from within the source tree, checkout the master branch, and run the <filename>./switchhere</filename> script: + </para> + <para> + <screen>$ <userinput>./switchhere</userinput></screen> + </para> + <para> + The <filename>./switchhere</filename> script does the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Symlink <filename>/etc/revisor/</filename> to <filename><replaceable>$PWD</replaceable>/conf/</filename> so that <filename>/etc/revisor/revisor.conf</filename>, the primary configuration file, and <filename>/etc/revisor/conf.d/</filename>, the configuration directory, are valid (the symlink causes the actual file and directory to be found in <filename><replaceable>$PWD</replaceable>/conf/</filename>) + </para> + </listitem> + <listitem> + <para> + Create the <filename>/usr/share/revisor/</filename> directory so that a couple of symlinks can be created from within that directory: + </para> + </listitem> + <listitem> + <para> + In Revisor 2.1.0 (development version in branch master), this includes: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/revisor/modgui/glade/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/revisor/modgui/glade/pixmaps/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + <listitem> + <para> + In Revisor 2.0.5 (branch F-7, F-8 or EL-5), this includes: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/glade/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/glade/pixmaps/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + <listitem> + <para> + In Revisor 2.1.0, also create symlinks from within the appropriate <filename>/usr/share/man/man<replaceable>$x</replaceable>/</filename> directories to the source for these man pages in <filename><replaceable>$PWD</replaceable>/doc/</filename>. + </para> + </listitem> + </itemizedlist> + </para> + <para> + From this moment on, you should be able to run: + </para> + <para> + <screen>$ <userinput>./revisor.py</userinput></screen> + </para> + <note> + <title>Root privileges required</title> + <para> + Note that revisor needs root privileges to run, and that you'll need to sudo or su-c to gain those. Use here whatever you find the most convenient; Revisor though should have a nice error message when run without those privileges. + </para> + </note> + + <section id="Revisor_Reference_Manual-Development-Running_Revisor_from_Source-Required_Packages"> + <title>Installing the Required Packages</title> + <para> + To be able to run Revisor from within the source tree, you'll need to install the required packages for each component, of course. + </para> + <para> + To get a current list of those packages, use: + </para> + <para> + <screen>$ <userinput>rpmquery --specfile --qf="%{REQUIRES}\n" revisor.spec | sort | uniq | xargs -n 1 repoquery --requires --alldeps --resolve</userinput></screen> + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Development-Building_Revisor_Packages"> + <title>Building Revisor Packages</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Tickets"> + <title>Tickets</title> + <para> + bugzilla, trac + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Adding_A_New_Spin"> + <title>Adding a new spin or remix</title> + <para> + <orderedlist> + <listitem> + <para> + Add the appropriate models in the appropriate configuration file for Revisor. + </para> + </listitem> + <listitem> + <para> + Add the appropriate configuration file to the appropriate automake Makefile + </para> + </listitem> + <listitem> + <para> + Run autoreconf && ./configure && make rpm to verify the rpm building + </para> + </listitem> + <listitem> + <para> + Create the model's YUM configuration files with the following repositories: + </para> + <para> + <itemizedlist> + <listitem> + <para> + fedora, enabled, pointing to Everything + </para> + </listitem> + <listitem> + <para> + fedora-source, disabled, pointing to Everything + </para> + </listitem> + <listitem> + <para> + fedora-updates, enabled, pointing to the updates repository + </para> + </listitem> + <listitem> + <para> + fedora-updates-source, disabled, pointing to the updates repository + </para> + </listitem> + <listitem> + <para> + anaconda-updates, enabled, pointing to the anaconda updates repository + </para> + </listitem> + <listitem> + <para> + anaconda-updates-source, disabled, pointing to the ananconda updates repository + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + </orderedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Versioning_Schema"> + <title>Versioning Schema</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Development-Release_Procedure"> + <title>Release Procedure</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Features.xml b/doc/Reference_Manual/en-US/Reference_Manual-Features.xml new file mode 100644 index 0000000..6321641 --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Features.xml @@ -0,0 +1,175 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Features"> + <title>Features</title> + <para> + Revisor allows you to build and customize your own Remix, Re-Spin, Spin or even your own distribution, based on Fedora and derivative distributions such as Red Hat Enterprise Linux and CentOS. + </para> + <para> + Revisor builds installation media, live media, installation trees, cobbler distro's and profiles, virtualization images and more. + </para> + + <section id="Revisor_Reference_Manual-Features-Installation_Media"> + <title>Installation Media</title> + <para> + Installation media is what you use to install a system with. The installation media composed will allow you to go through the installation process, answering a number of questions (either manually or through kickstart), and ends up in a system running the distribution you install. + </para> + <para> + Composing installation media using the Revisor GUI allows you to choose the media (CD, or DVD), the packages to be included on the media (also called <emphasis>RPM payload</emphasis>). + </para> + <para> + Using the command-line interface, Revisor also allows you to choose DVD Duallayer and single- or dual-layer Bluray. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Installation_Trees"> + <title>Installation Trees</title> + <para> + Installation trees are typically used in environments where a distribution needs to be deployed over multiple systems, or is very volatile. Installation trees are often made accessible through HTTP or FTP protocols, in one place, and do not have as much overhead (in creating .iso files, and burning those to optical media to distribute them). + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Live_Media"> + <title>Live Media</title> + <para> + Live media often is a perfect showcase for an Operating system, Desktop Environment or any other thing you want to show. Also, since Live media is read-only, live media perfectly allows for a kiosk system, a system that may change while it's running, but restores all original settings when rebooted. + </para> + <para> + Live media is also installable. You start out with a system and boot it from live media, then choose to install the live media. This however is inferior to real installation media, but is convenient if you happen to like what you see when running from live media. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Reproducibility"> + <title>Reproducibility</title> + <para> + Media composed with Revisor is extremely reproducible. Using <literal>kickstart_exact_nevra</literal>, you can even select specific versions of packages to be included on the product. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Consistency"> + <title>Consistency</title> + <para> + When composing different types of media, such as CDs and DVDs, Revisor composes these discs in one run, making the different media completely consistent. <application>pungi</application> would require you to run twice, once for CDs, and once for DVDs. This is because <application>pungi</application> uses the <literal>part / <replaceable><size></replaceable></literal> kickstart configuration directive to set the maximum size of the media, and has no option to override the size on the command-line, nor to compose a certain set of media (it all depends on the size). + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Flexibility"> + <title>Flexibility</title> + <para> + Over the years, Revisor has been adopted to serve a large number of use-cases, where use-cases stretch from media being composed as efficient as possible, as robust as possible, specific deployment needs and expectations, and to match the Fedora Project Release Engineering tools' behaviour. All this allows you to configure a lot, and thus customize a lot, making Revisor more of a flexible framework. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Graphical_User_Interface"> + <title>Graphical User Interface</title> + <para> + Revisor has a Graphical User Interface or GUI, in addition to the Command Line Interface or CLI, which makes Revisor more accessible to users then the other tools, which are CLI only. Most people only know of Revisor through the GUI, and may think there is no CLI to Revisor. Only when it comes down to many of the additional features that Revisor has, and that do not fit in a simplified GUI, one gets down with it using the CLI. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Open_Development_Community"> + <title>Open Development Community</title> + <para> + Revisor has one of those old-fashioned Free and Open Source Software development communities, allowing anyone to make a contribution to Revisor. In fact, Revisor has not bounced a single patch since the project started. Therefor, it improves faster then any of the other compose tools, and is better adaptible to your needs and expectations, because unlike the other utilities, Revisor is not limited to use-cases that apply to Fedora Project Release Engineering. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Plugin_System"> + <title>Plugin System</title> + <para> + Revisor has a plugin system so that you can easily extend Revisor. This plugin system gives you full control over the Revisor procedures, and hands you off anything Revisor knows about the compose process. There's are multiple plugins available from upstream as well. To give you an example, the ability to replace <filename>isolinux.cfg</filename> after the compose is done, is a plugin. See <xref linkend="Revisor_Reference_Manual-Plugins" /> for more information. + </para> + + <para> + Current plugins included with Revisor include: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Cobbler_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Rebrand_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Reference_Manual-Plugins-Upstream-Reuse_Installer_Images_Plugin" /> + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Extraneous_Debugging"> + <title>Extraneous Debugging</title> + <para> + Revisor has extraneous debugging, which enables you, as well as the supporters and Revisor's developers, to trace down what happens exactly, and where anything might go wrong. + </para> + </section> + + <section id="Revisor_Reference_Manual-Features-Using_YUM_Configuration_Files"> + <title>Using YUM Configuration Files</title> + <para> + Revisor uses YUM configuration files, where everyone else is not. With using YUM configuration files however, the control you have is nearly limitless. With all the features in YUM already, using it's configuration file format and letting YUM itself work with those allows Revisor to do a lot of cool things without doing anything itself: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Excluding packages from repositories</title> + <para> + Excluding packages from repositories means a great deal. Not having them exist in the <xref linkend="Revisor_Reference_Manual-Appendix-Terminology-Package_Sack" /> ensures the package will not end up in the product. This may be what you want for maybe just a few, or maybe an awful lot of packages. + </para> + </formalpara> + <para> + Using the alternative configuration file format, kickstart, in use by every other compose tool, and the <literal>repo</literal> configuration directive that is available with kickstart, you can exclude packages using the <literal>--exclude=</literal> parameter to the <literal>repo</literal> configuration directive. However, that parameter does not allow wildcard matches. + </para> + </listitem> + <listitem> + <formalpara> + <title>Including only a certain (set of) package(s)</title> + <para> + Including only a certain package, or certain set of packages is valuable when a lot of packages exist in the repository configured, but you only need one or two. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Concurrent use of baseurl(s) and the mirrorlist</title> + <para> + Like during normal YUM operations, the baseurl(s) and the mirrorlist configured for a repository are used concurrently. This is not possible with the kickstart configuration directive <literal>repo</literal>, which takes either <literal>--baseurl</literal> or <literal>--mirrorlist</literal>, but not both. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Repository priorities</title> + <para> + Settings available with YUM are available within Revisor as well, like repository priorities. Using repository priorities, you can have YUM decide to pull a package from the repository with a higher priority (a lower priority number) rather then a repository with a lower priority. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>YUM Plugins</title> + <para> + YUM plugins, such as <application>yum-fastestmirror</application>, <application>yum-fedorakmod</application>, are available, giving you even more control over the behaviour of YUM. + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + </section> +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Frequently_Asked_Questions.xml b/doc/Reference_Manual/en-US/Reference_Manual-Frequently_Asked_Questions.xml new file mode 100644 index 0000000..7e97e0e --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Frequently_Asked_Questions.xml @@ -0,0 +1,54 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Frequently_Asked_Questions"> + <title>Frequently Asked Questions</title> + <para> + para + </para> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-How_Does_Revisor_Handle_Comps"> + <title>How Does Revisor Handle Comps?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-What_Are_Installer_Images"> + <title>What Are Installer Images?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Pungi"> + <title>What is the relationship between Revisor and Pungi?</title> + <para> + Where pungi builds a bunch of RPMs into ISO images and installation trees through one single procedure, perfect for Release Engineering on something like the Fedora Project, Revisor does it different entirely. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Livecd-tools"> + <title>What is the relationship between Revisor and livecd-tools?</title> + <para> + Revisor depends on livecd-tools for the composing of live media. Creating the filesystem to install the packages to, turning that image file into a SquashFS file, and applying the settings inside the chroot. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-Why_Rebuild_Installer_Images"> + <title>Why Rebuild Installer Images?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Frequently_Asked_Questions-How_do_I_create_an_updates.img"> + <title>How do I create an updates.img?</title> + <para> + para + </para> + </formalpara> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Installation.xml b/doc/Reference_Manual/en-US/Reference_Manual-Installation.xml new file mode 100644 index 0000000..f56855f --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Installation.xml @@ -0,0 +1,104 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Installation"> + <title>Installation</title> + <para> + This chapter contains the installation instructions for Revisor. + </para> + + <section id="Revisor_Reference_Manual-Installation-Packages"> + <title>Packages</title> + <para> + You can install Revisor using RPM packages from the repositories already configured on your system. + </para> + + <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor"> + <title><application>revisor</application></title> + <para> + Shorthand package for the Revisor GUI. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor-cli"> + <title><application>revisor-cli</application></title> + <para> + The CLI version of Revisor. This package is always installed, as it contains the Python code for Revisor's core. Installing just this package will give you the command-line version of Revisor, and prevents the graphical dependencies from the <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor-gui" /> package to be installed as well. + </para> + </formalpara> + + <formalpara id="Revisor_Reference_Manual-Installation-Packages-revisor-gui"> + <title><application>revisor-gui</application></title> + <para> + The GUI version of Revisor. This is the actual package containing the Graphical User Interface, as opposed to <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor" />. Depends on <xref linkend="Revisor_Reference_Manual-Installation-Packages-revisor-cli" />, and thus also installs the command-line version of Revisor. + </para> + </formalpara> + + <section id="Revisor_Reference_Manual-Installation-Packages-YUM-RHEL"> + <title>Red Hat Enterprise Linux 5 or higher</title> + <para> + On Red Hat Enterprise Linux 5 or higher, and derivatives, install the Extra Packages for Enterprise Linux (EPEL) repository. + </para> + <para> + Then, give the following command: + </para> + <para> + <screen># <userinput>yum install revisor</userinput></screen> + </para> + </section> + + <section id="Revisor_Reference_Manual-Installation-Packages-YUM-Fedora"> + <title>Fedora 7 or higher</title> + <para> + On Fedora 7 or higher, and derivatives, no additional repository configuration is required. + </para> + <para> + Give the following command: + </para> + <para> + <screen># <userinput>yum install revisor</userinput></screen> + </para> + <note> + <title>About EOL Releases</title> + <para> + Please bear in mind that Fedora releases that are past the point of End-Of-Life, approximatly 13 months after the initial release, are not supported anymore for use with Revisor. Also, the version of Revisor running on these EOL versions of Fedora are not supported anymore. + </para> + </note> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Installation-The_Latest_And_Greatest"> + <title>The Latest and Greatest</title> + <para> + The latest and greatest is available from GIT, at <ulink url="git://git.fedorahosted.org/revisor" />. To clone this repository, use: + </para> + <para> + <screen>$ <userinput>git clone git://git.fedorahosted.org/revisor/</userinput></screen> + </para> + <para> + Using the GIT clone, you have the several options to start using the latest and greatest: + </para> + <formalpara> + <title>Running directly from the source</title> + <para> + You can run directly from within the source tree. See <xref linkend="Revisor_Reference_Manual-Development-Running_Revisor_from_Source" /> for more information on how to do so. + </para> + </formalpara> + <warning> + <title>Installed packages and running from source</title> + <para> + Do not run Revisor from source while RPM packages have been installed. Files managed by a package will get created, moved and removed when using Revisor's source tree, and updates to the installed RPM packages will destroy these changes. + </para> + </warning> + <formalpara> + <title>Building your own packages</title> + <para> + You can create your own packages, so that you have all the benefits of RPM. See <xref linkend="Revisor_Reference_Manual-Development-Building_Revisor_Packages" /> for more information on how to do so. + </para> + </formalpara> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Introduction.xml b/doc/Reference_Manual/en-US/Reference_Manual-Introduction.xml new file mode 100644 index 0000000..561b37c --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Introduction.xml @@ -0,0 +1,71 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Introduction"> + <title>Introduction</title> + <para> + Revisor is a community product by Fedora Unity. Amongst other features, it allows the creation of installation media and live media in the easiest possible manner, through a click-and-go GUI. This chapter gives some insight on how and why Revisor was born, and how the product evolved since. + </para> + + <section id="Revisor_Reference_Manual-Introduction-History_Of_Revisor"> + <title>History of Revisor</title> + <para> + Revisor development started in December 2006, during the Fedora 7 development cycle, in which -you might recall- the Fedora Core repository, maintained by Red Hat, and Fedora Extras repository, mostly maintained by the community, were merged into one large repository being maintained by both community members as well as Red Hat employees -which are mostly community members hired by Red Hat -so community altogether. Before then Red Hat employees maintained Fedora Core -as the set of packages upstream for Red Hat's Enterprise product- and the community maintained a repository with additional software; Fedora Extras. Red Hat composed the Fedora distribution every once in a while, but the merge introduced the possibility for packages that were in Fedora Extras to be included in the main distribution, and for the community to also (co-)maintain the (former) Fedora Core packages that originally made up the distribution. + </para> + <para> + In addition to this huge merge of packages, Red Hat employees were also able to release the entire build process to the community, meaning that from the moment the source is committed up and until the release is announced, the entire process is open. Not that is was all behind closed doors or proprietary or anything, the community just couldn't really play with it as much. We now have koji (build system), mash (repository compose from build system products), bodhi (updates release system), livecd-tools (compose tool for live media) and pungi (compose tool for installation media). + </para> + <para> + Composing media was an obscure process up and until the moment these tools exposed the best way to compose (a set of) installation media. Fedora Unity had been building and releasing so-called Re-Spins1 regularly, but they were built using a not-so-very intelligent bash script. Like hundreds if not thousands of other parties that needed to build their own media one way or the other, the entire process was based on the best educated guess of what should happen. Luckily, in the FOSS world an educated guess is often a very good guess, despite the fact that one keeps learning even years after the original engagement. + </para> + <para> + When in December 2006 the compose tools hit a stage in which they were released to the public, Fedora Unity was eager to get these tools and study them and use them for composing their Re-Spins. Up and until then, Re-Spins were composed with the aforementioned bash script that didn't do much but trigger the appropriate commands in a sequence; There wasn't any dependency resolving between the packages included nor did we know exactly how a release was supposed to be composed -it was our educated guess of how it could happen. Although it often led to success, we've had many, many failed Re-Spins as well. With a handful of volunteers, you can imagine the amount of frustration that might give. Fedora Unity was eager to improve their Re-Spin process. + </para> + <para> + So, early February 2007, a number of Fedora Unity members attended “FUDCon 2007” in Boston, and presented a working GUI front-end to livecd-tools and pungi enabling regular users to also re-compose or re-spin the installation media and live media they had been getting from the Fedora Project. Revisor at this point just made it “as easy as possible”. Besides the possibilities of pungi and livecd-tools themselves, the wizard Revisor had apparently was very, very useful to mere mortals. From that point on, things took off. + </para> + <para> + Fedora Unity decided Revisor could accomplish more then just being a front-end to existing compose tools and enable someone to tweak a lot of settings as well. In March 2007, Revisor was rebuild from the ground up in March 2007 to allow a more flexible process, more dependent on the configuration directives it was given and less so on the processes of the existing tools. When in San Diego at the Red Hat Summit (early May 2007), Robert 'Bob' Jensen and Jonathan Steffan gave a presentation on “Customizing Fedora”, the responses were amazing. Since then Revisor has evolved from a front-end to existing tools to the complete compose tool it is today, with lots of configuration options for specific use-cases. + </para> + <para> + For users, Revisor is particularly useful because it has a GUI front-end wizard, which, with the defaults settings, will just succeed in getting a user the media he/she wants. If a user decides he needs little adjustment of the media, the GUI allows for selecting the most common options. If a user decides he needs some less common adjustments, the configuration options gives him very granular control -and as long as the documentation on all the options is sufficient, users will be able to make those less common adjustments. + </para> + <para> + For administrators on the other hand, Revisor is the tool that gives so much granular control over what happens, that it can serve almost every specific use-case. In this aspect, Revisor could potentially replace the compose tools administrators have been developing themselves with a consistent and flexible program flow. + </para> + <para> + This document should enable you to study the process of composing installation and live media, and comprehend the logic Revisor adds to that process. + </para> + </section> + + <section id="Revisor_Reference_Manual-Introduction-The_Installation_Media_Challenge"> + <title>The Installation Media Challenge</title> + <para> + When Fedora Unity first started doing these so-called Re-Spins, the challenge ahead could maybe be explained like this: + </para> + <para> + <emphasis>When a user downloads a Fedora release and installs the distribution, the user will need to download and install a number of updates. The “older” the release becomes, the more updates will be available, and the greater the total download size of these updates the user will need to download on top of the download size of the original release media.</emphasis> + </para> + <para> + “older” is in quotes on purpose, because really for an operating system -or “distribution” if you will- being released every 6 months, “old” is quite a relative concept. The number of updates available however, at any given time during the release cycle, may range from 0 right after the release (which has never happened before), to the total amount of packages installed on the user's system (often over 2000). You can imagine the size of these updates ranging from 0 MB to an astonishing 2GB(!), only 6 months after the initial release. + </para> + <para> + Some of us do not have the bandwidth capacity or enough data transfer quota to download this many extra, rather useless bits. In addition, some of us do not have an Internet connection at all, and thus benefit getting the updates from Re-Spins directly. + </para> + <para> + The use of updates in Re-Spins has several more beneficial side-effects, which we'll explain in more detail later on in this document. Long story short; If for some reason the software used to compose the media (the release) with does not work for your hardware or your specific needs, updated software incorporated in the composed installer images might resolve that problem. + </para> + <para> + This is the original challenge the Fedora Unity team resolved a long time ago, and is at the base of what Revisor does nowadays. + </para> + </section> + + <section id="Revisor_Reference_Manual-Introduction-The_Live_Media_Challenge"> + <title>The Live Media Challenge</title> + <para> + Back in the day Fedora Core 5 was the most recent release, Fedora Unity created so-called live media using Kadischi. In that time, live media could only have a read-only root file system and was not as feature-rich as live media is today. However, just before Revisor came to life, two applications were developed; pungi for creating installation media, and livecd-tools for creating live media. These two applications did their work well; The media composed for a release, including many different custom live media spins were, and still are, created with these tools. Immediately, the Revisor developers set themselves a target to provide a single interface to both of those tools. + </para> + </section> + +</chapter> diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Plugins.xml b/doc/Reference_Manual/en-US/Reference_Manual-Plugins.xml new file mode 100644 index 0000000..122f25e --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Plugins.xml @@ -0,0 +1,131 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Plugins"> + <title>Plugins</title> + <para> + para + </para> + + <section id="Revisor_Reference_Manual-Plugins-Upstream"> + <title>Upstream Plugins</title> + <para> + Plugins available from upstream, maintained by upstream + </para> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Cobbler_Plugin"> + <title>Cobbler Plugin</title> + <para> + The Cobbler plugin is able to put the product composed into a Cobbler environment, by handing off the built product to the existing Cobbler infrastructure as a <emphasis>distro</emphasis>, and creating a <emphasis>profile</emphasis>. + </para> + <para> + Using this module, one can automatically import the Revisor product into a Cobbler environment, and immediately use the new Cobbler <emphasis>profile</emphasis> to start deploying or automated testing, maybe. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Composer_Plugin"> + <title>Composer Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Delta_Plugin"> + <title>Delta Plugin</title> + <para> + A small change to a ISO image does not require you to download the complete ISO image if you have a copy of the old ISO image. + </para> + <note> + <title>Only applicable to (...)</title> + <para> + The generation of Delta ISO images is only applicable to situations in which the ISO image does not contain SquashFS images. SquashFS images are smaller, but all SquashFS images are unique. Since the Delta principle is based on similarities, and no two SquashFS images are alike, creating a Delta on two ISO images containing SquashFS images will lead to a Delta pratically the same size as the SquashFS image. For Live Media that compresses the ext3 filesystem image into a SquashFS image, since that SquashFS image is probably over 97% of the size of the ISO image, creating Delta images for compressed Live Media does not make sense. For installation media however, most RPMs would be similar as well as (potentially) the installer images. + </para> + </note> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-GUI_Plugin"> + <title>GUI (Graphical User Interface) Plugin</title> + <para> + Yes, the Graphical User Interface for Revisor is actually a plugin. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-HUB_Plugin"> + <title>HUB Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Isolinux_Plugin"> + <title>Isolinux Plugin</title> + <titleabbrev id="Isolinux_Plugin">Isolinux Plugin</titleabbrev> + <para> + The isolinux plugin adds the <literal>--isolinux-cfg</literal> command-line option to Revisor. Specify a file here, and the original <filename>isolinux.cfg</filename> that is built as part of the compose process is replaced by the <filename>isolinux.cfg</filename> specified. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Jigdo_Plugin"> + <title>Jigdo Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Mock_Plugin"> + <title>Mock Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Rebrand_Plugin"> + <title>Rebrand Plugin</title> + <para> + The rebrand plugin hooks in to Revisor at several different stages. The goal of this plugin is to ensure no trademarked packages end up on the media. Trademarked packages may include <application>fedora-logos</application>, <application>redhat-logos</application>, and so forth. + </para> + <para> + The plugin adds a <literal>--rebrand</literal> option, to which you can specify the name of your new product. When rebranding Fedora to Omega for example, specifying <literal>--rebrand Omega</literal> would be sufficient to make sure the product does not have any Fedora trademarks. + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Reuse_Installer_Images_Plugin"> + <title>Reuse Installer Images Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Server_Plugin"> + <title>Server Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-Virtualization_Plugin"> + <title>Virtualization Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Plugins-Upstream-WUI_Plugin"> + <title>WUI (Web-based User Interface) Plugin</title> + <para> + para + </para> + </section> + + </section> + + <section id="Revisor_Reference_Manual-Plugins-Writing_Your_Own"> + <title>Writing Your Own Plugins</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Testing.xml b/doc/Reference_Manual/en-US/Reference_Manual-Testing.xml new file mode 100644 index 0000000..ea4ff00 --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Testing.xml @@ -0,0 +1,173 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Testing"> + <title>Testing</title> + <para> + The following test cases describe different types of testing a new Revisor release. + </para> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases"> + <title>Simple Test Cases</title> + <para> + This section has a few simple test cases ensuring configuration shipped with Revisor works as anticipated. + </para> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_cases-Packages"> + <title>Packages</title> + <para> + Install the <application>revisor-cli</application>: + </para> + <para> + <screen># <userinput>yum --enablerepo=updates-testing install revisor</userinput></screen> + </para> + <para> + Installed are all dependencies for the Revisor CLI interface. Make sure <application>spin-kickstarts</application> is installed, a package for sample kickstarts. + </para> + <para> + Starting Revisor as follows should not show any error messages related to Revisor attempting to start up it's GUI interface: + </para> + <para> + <screen># <userinput>revisor</userinput></screen> + </para> + + <formalpara> + <title>Configuration Files</title> + <para> + The following configuration files should exist: + </para> + </formalpara> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/etc/revisor/revisor.conf</filename> + </para> + </listitem> + </itemizedlist> + </para> + <para> + Each section should have a configuration file listed as <literal>main</literal>. + </para> + <para> + And, of course, every configuration file listed in each section. In this case, the following snippet is easy enough: + </para> + <para> + <screen>$ <userinput>i=0; \ +configfiles="`grep ^main /etc/revisor/revisor.conf | \ + sed -r -e 's/^main.*=\s*(.*)/\1/g'`" + +for configfile in $configfiles; do \ + [ ! -f $file ] && i=1; \ +done; \ +echo $i</userinput></screen> + </para> + <para> + Another way to test the configuration file is to execute: + </para> + <para> + <screen>$ <userinput>revisor --list-models >/dev/null</userinput></screen> + </para> + <para> + If everything is well, since <literal>STDOUT</literal> is redirected to <filename>/dev/null</filename>, you should see no messages at all. + </para> + + </section> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases-Configuration_Files"> + <title>Configuration Files</title> + <para> + The main Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. The file lists a series of models, each having their own YUM configuration file in <filename>/etc/revisor/conf.d/</filename>. + </para> + <formalpara> + <title>Testing</title> + <para> + <itemizedlist> + <listitem> + <para> + For each model in <filename>/etc/revisor/revisor.conf</filename>, the <code>main</code> setting for that model should point to a valid file. + </para> + </listitem> + <listitem> + <para> + Each YUM configuration file should work. To verify, run the following command for each configuration file: + </para> + <para> + <screen>$ yum -c <replaceable>$file</replaceable> list kernel</screen> + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>Known Errors</title> + <para> + <itemizedlist> + <listitem> + <para> + Revisor has baseurls in YUM repositories set to <ulink url="http://localrepo" />. This URL will not be retrievable for many people, but allows the developers to quickly change mirrors. + </para> + </listitem> + <listitem> + <para> + Repositories that are unavailable at the moment of testing will throw errors Revisor can't do anything about. + </para> + </listitem> + <listitem> + <para> + If the directories <filename>revisor-yumcache/</filename> and <filename>revisor/</filename> in <filename>/var/tmp/</filename>, the default working directory, are not writeable for the user then YUM will throw permission denied errors. + </para> + <para> + Remove <filename>/var/tmp/revisor/</filename> and <filename>/var/tmp/revisor-yumcache/</filename> or run the command with root permissions. + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + </section> + + <section id="Revisor_Reference_Manual-Testing-Simple_Test_Cases-Compose_Results"> + <title>Requirements for Compose Results</title> + <para> + Although heavily dependent on Anaconda for this part, these are still requirements + </para> + + <formalpara> + <title>ld-linux.so.2</title> + <para> + In the <filename>initrd.img</filename> of the composed product, if 32-bit, <filename>/lib/ld-linux.so.2</filename> (or any other version) should link to <filename>/lib/ld-2.9.so</filename> (or any other version). If <filename>/lib/ld-linux.so.2</filename> links to itself, the media will fail to install. + </para> + </formalpara> + <formalpara> + <title>How to test</title> + <para> + In a terminal, type the following command: + </para> + </formalpara> + <para> + <screen>$ <userinput>lsinitrd /path/to/initrd | grep ld-linux</userinput></screen> + </para> + <para> + See also: <ulink url="https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00115.…" /> + </para> + + </section> + </section> + + <section id="Revisor_Reference_Manual-Testing-Complex_Test_Cases"> + <title>Complex Test Cases</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Testing-Specific_Test_Cases"> + <title>Specific Test Cases</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Tips_and_Tricks.xml b/doc/Reference_Manual/en-US/Reference_Manual-Tips_and_Tricks.xml new file mode 100644 index 0000000..8b785ee --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Tips_and_Tricks.xml @@ -0,0 +1,47 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Tips_and_Tricks"> + <title>Tips and Tricks</title> + <para> + para + </para> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-The_spin-kickstarts_Package"> + <title>The spin-kickstarts Package</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-Even_More_Debugging"> + <title>Even More Debugging</title> + <para> + something about using -x to buildinstall scripts + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-ksvalidator"> + <title>Kickstart Validator</title> + <para> + something about using -x to buildinstall scripts + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-Using_Mirrormanager_For_Mirror_Redirection"> + <title>Using Mirrormanager for Mirror Redirection</title> + <para> + Something about using Mirrormanager to redirect you to the local mirror (so you do not have to edit YUM configuration files). + </para> + </section> + + <section id="Revisor_Reference_Manual-Tips_and_Tricks-The_localrepo_DNS_Alias"> + <title>Using The localrepo DNS Alias</title> + <para> + Something about using the localrepo DNS alias to point to your local mirror (either through real DNS or through /etc/hosts), so you do not have to edit the YUM configuration files. + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Tweaking_The_Build_Process.xml b/doc/Reference_Manual/en-US/Reference_Manual-Tweaking_The_Build_Process.xml new file mode 100644 index 0000000..4979285 --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Tweaking_The_Build_Process.xml @@ -0,0 +1,40 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Tweaking_The_Build_Process"> + <title>Tweaking the build process</title> + <para> + para + </para> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Reusing_Existing_Installer_Images"> + <title>Reusing Existing Installer Images</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Building_The_Installer_Images_In_Mock"> + <title>Building The Installer Images in Mock</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Omitting-isomd5sum"> + <title>Omitting isomd5sums</title> + <para> + para + </para> + </section> + + <section id="Revisor_Reference_Manual-Tweaking_The_Build_Process-Omitting-sha1sums"> + <title>Omitting SHA1SUMS</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual-Using_Kickstart.xml b/doc/Reference_Manual/en-US/Reference_Manual-Using_Kickstart.xml new file mode 100644 index 0000000..f3e6ab2 --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual-Using_Kickstart.xml @@ -0,0 +1,118 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Reference_Manual-Using_Kickstart"> + <title>Using Kickstart</title> + <para> + Kickstart is a configuration file format for automating installation procedures. Or at least, it was, originally. Nowadays, kickstart files are used as input to the compose tools, including Revisor. + </para> + <para> + Revisor again is unique in that it does not require a kickstart file for input. The other tools only take kickstart configuration files. Revisor though allows most of what is in a kickstart file to be configured interactively in Graphical User Interface mode. + </para> + + <section id="Revisor_Reference_Manual-Using_Kickstart-How_Kickstart_Is_Used"> + <title>How Kickstart Is Used</title> + <para> + There's two cases in which a kickstart file is used differently. One is during the compose of installation media, and the other of course is during the compose of live media, or virtualization media. + </para> + + <section id="Revisor_Reference_Manual-Using_Kickstart-How_Kickstart_Is_Used-Installation_Media"> + <title>Installation Media</title> + <para> + In the case of installation media, the following settings are used: + </para> + <para> + <itemizedlist> + <listitem> + <formalpara> + <title><literal>repo</literal></title> + <para> + The <literal>repo</literal> command in kickstart is used when Revisor is configured to use the repositories configured in the kickstart file only. Use <literal>kickstart_repos = 1</literal> to enable this feature, or set the appropriate checkbox in the Revisor GUI. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><literal>%packages</literal></title> + <para> + The <literal>%packages</literal> section in kickstart is used to determine the RPM payload on the installation media. It can include groups and packages, and exclude packages. It accepts wildcards, both in includes and excludes of packages (but not groups). + </para> + </formalpara> + </listitem> + </itemizedlist> + </para> + <note> + <title>@core and @base</title> + <para> + By default, groups @core and @base are included in the package manifest. You can specify @base to not be included, by using <literal>%packages --nobase</literal>, but @core cannot be excluded using a kickstart package manifest. + </para> + </note> + <para> + Using <literal>kickstart_exact</literal>, you can exclude @core and @base so that you need to explicitly select them in the kickstart package manifest. + </para> + <para> + Using <literal>kickstart_exact_nevra</literal> ... + </para> + </section> + </section> + + <section id="Revisor_Reference_Manual-Using_Kickstart-The_Kickstart_Package_Manifest"> + <title>The Kickstart Package Manifest</title> + <para> + para + </para> + + <formalpara> + <title>Group @core</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Group @base</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Including groups of packages</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Including a single package</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Excluding a single package</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Using wildcard matches</title> + <para> + para + </para> + </formalpara> + + <section id="Revisor_Reference_Manual-Using_Kickstart-Using_Kickstart_With_Package_NEVRA"> + <title>Using Kickstart with Package NEVRA</title> + <para> + para + </para> + </section> + + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual.xml b/doc/Reference_Manual/en-US/Reference_Manual.xml index 757504d..7962278 100644 --- a/doc/Reference_Manual/en-US/Reference_Manual.xml +++ b/doc/Reference_Manual/en-US/Reference_Manual.xml @@ -6,18 +6,18 @@ <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Features.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Installation.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Configuration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Using_Kickstart.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Compose_Process_Details.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Plugins.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Tweaking_The_Build_Process.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Tips_and_Tricks.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Frequently_Asked_Questions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Testing.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Development.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Features.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Installation.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Configuration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Using_Kickstart.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Compose_Process_Details.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Plugins.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Tweaking_The_Build_Process.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Tips_and_Tricks.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Frequently_Asked_Questions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Testing.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Reference_Manual-Development.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <index /> diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Compose_Process_Details.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Compose_Process_Details.xml deleted file mode 100644 index 64515ff..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Compose_Process_Details.xml +++ /dev/null @@ -1,431 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Compose_Process_Details"> - <title>Compose Process Details</title> - <para> - This chapter lists the details of the compose process as well as dives deep into the features of Revisor. - </para> - - <section id="Revisor_Documentation-Compose_Process_Details-Overview"> - <title>Overview</title> - <titleabbrev id="Compose_Process_Details-Overview">Overview</titleabbrev> - <para> - Of course, the compose process for installation media is a little different then the compose process for live media. - </para> - <para> - When composing, Revisor starts out doing the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Revisor initiates and loads plugins, options, and defaults. At this point, Revisor has a so-called <emphasis>ConfigStore</emphasis> that holds all options Revisor knows about. - </para> - </listitem> - <listitem> - <para> - Revisor reads the options from the command-line. - </para> - </listitem> - <listitem> - <para> - Revisor reads the configuration file specified with the <code>--config</code> command-line parameter, or uses it's builtin default, <filename>/etc/revisor/revisor.conf</filename>. - </para> - </listitem> - <listitem> - <para> - Revisor reads the global <code>[revisor]</code> section for all settings available in it's <emphasis>ConfigStore</emphasis> and sets those configured in the global section. Remember that if an option is not available in the <emphasis>ConfigStore</emphasis> but is configured in the global configuration section, it is ignored. - </para> - </listitem> - <listitem> - <para> - If a model is specified in the configuration file's global section <code>[revisor]</code>, Revisor will set that model to be used and loads it. - </para> - </listitem> - <listitem> - <para> - If a model has been specified on the command-line, with option <code>--model</code>, Revisor loads that model. - </para> - </listitem> - <listitem> - <para> - When loading the model, Revisor again iterates over all the settings that are in the <emphasis>ConfigStore</emphasis>, checks if the setting has been configured in the model section, and adjusts the setting in the <emphasis>ConfigStore</emphasis> if necessary. Again remember that if the <emphasis>ConfigStore</emphasis> does not know about one or the other option already, that setting is ignored. - </para> - </listitem> - <listitem> - <para> - Now that the defaults and configuration file settings have been applied to the <emphasis>ConfigStore</emphasis>, it is time for Revisor to look at the options specified on the command-line to see if you wanted to override anything. - </para> - </listitem> - <listitem> - <para> - While loading each configuration setting available in the global <code>[revisor]</code>, model-specific sections and/or command-line, Revisor checks every settings against a function that is specifically written to check such setting. For example, the label of an ISO cannot be longer then 32 characters. - </para> - </listitem> - <listitem> - <para> - Especially in CLI mode, these settings build up the task list for Revisor. If there's nothing to do, Revisor will throw an error explaining what's missing. If there's things to do that cannot be done in one run, Revisor will throw an error explaining that. - </para> - </listitem> - <listitem> - <para> - In Graphical User Interface mode however, if the settings loaded so far are all OK, the GUI will start. Since you can still adjust a few settings from within the GUI, the settings loaded so far will be the defaults for configuration settings that have a dialog for you to adjust them with, throughout the rest of the process. - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Installation_Media"> - <title>Installation Media</title> - <para> - As we've explained before, composing installation media is a little different then composing live media. That's not just because installation media should start an installation procedure and live media should show you a nice, shiny, fully-functional Desktop. - </para> - <para> - For one, installation media allows split media. This means that Revisor can span the payload of the product over multiple ISO images or multiple discs, if you will. When composing installation media, Revisor basically does the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Of course, Revisor goes through the loading of configuration options mentioned in the <xref linkend="Revisor_Documentation-Compose_Process_Details-Overview" endterm="Compose_Process_Details-Overview" />. - </para> - </listitem> - <listitem> - <para> - When you're done specifying options in the GUI, or when Revisor thinks it can go ahead using the options specified in CLI mode, it takes the list of packages selected from either the GUI or the kickstart <code>%packages</code> manifest. - </para> - <para> - Not getting too deep into details here, yet, because some of these things are routines shared with other composing modes, but here's a few additional considerations Revisor makes when doing the package selection. - </para> - <para> - <itemizedlist> - <listitem> - <para> - Normally, a kickstart <code>%packages</code> manifest only allows you to select package <emphasis>names</emphasis>. With Revisor though, you can select exact package <emphasis>NEVRA</emphasis> to select a certain version or architecture for the package that you want. Additionally, if a package is not available, Revisor searches the <emphasis>Provides</emphasis> of the available packages. - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Live_Media"> - <title>Live Media</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Respin_Mode"> - <title>Respin Mode</title> - <para> - Revisor has a respin mode that in some aspects differs from the regular routines. It is intended to reflect behaviour of tools in use by the Fedora Project Release Engineering team as closely as possible. - </para> - <para> - Re-Spin mode only affects installation media products. - </para> - <para> - In Re-Spin mode, the way the RPM payload is determined from kickstart differs from Revisor's normal procedures. See <xref linkend="Revisor_Documentation-Using_Kickstart" /> for more details on using a kickstart package manifest. - </para> - <para> - A kickstart file's so-called <xref linkend="Revisor_Documentation-Appendix-Terminology-package_manifest" /> usually looks like: - </para> - <para> - <screen>%packages -@group1 -@group2 --nodefaults -@group3 --optional -package1 -package2 --package3 -%end</screen> - </para> - <para> - Which tells us the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Include all mandatory and default packages from group1 - </para> - </listitem> - <listitem> - <para> - Include all mandatory packages from group2 - </para> - </listitem> - <listitem> - <para> - Include all mandatory, default and optional packages from group3 - </para> - </listitem> - <listitem> - <para> - Include package1, and package2 - </para> - </listitem> - <listitem> - <para> - Exclude package3 - </para> - </listitem> - </itemizedlist> - </para> - <para> - Depending on how you use this instructions or information, there is a slight difference in the package set that ends up on the media you compose. - </para> - - <section id="Revisor_Documentation-Compose_Process_Details-Respin_Mode-Selecting_Groups"> - <title>Selecting Groups</title> - <para> - Selecting groups has the following logic: When you load a repository you may also load the groups file (often referred to as 'comps' or 'comps.xml'). This comps file is an XML file with categories, groups (per category), and per group: - </para> - <para> - <itemizedlist> - <listitem> - <para> - a list of mandatory packages. If you select or include the group, these packages come with it. - </para> - </listitem> - <listitem> - <para> - a list of default packages. If you select or include the group, these packages will come with it as a default. If you only want the mandatory, minimum set of packages for this group, in a kickstart package manifest append <code>--nodefaults</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Deselect all packages</emphasis>. - </para> - </listitem> - <listitem> - <para> - a list of optional packages. If you select a group you have not yet selected these packages. To select the optional packages of a group, in a kickstart package manifest append <code>--optional</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Select all optional packages</emphasis>. - </para> - </listitem> - <listitem> - <para> - a list of conditionals. If you select this group, these conditionals are thrown into the package sack and transaction information and include or exclude other packages. Suppose you select the '@nl-support' or “Dutch Support” group from the Languages or Localization category, you would end up with support for the Dutch language in all applications that have that kind of support. - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Respin_Mode-Select_Matching_Packages"> - <title>Select Matching Packages</title> - <para> - This is the logic Revisor applies when running in Re-Spin mode (on the CLI, specify <code>--respin</code>). It imitates the behavior pungi has, and thus enables you to copy that behavior. Note that <code>--respin</code> has other implications as well. - </para> - <para> - First of all, it iterates the groups in the kickstart package manifest. For each group, it appends the names of the mandatory packages to a list, and depending on the additional parameters specified with that group (<code>--nodefaults</code> or <code>--optional</code>), appends the names of the other packages in that group as well. - </para> - <para> - Then it iterates over the package names in the package manifest. These package names are appended to the same list of package names too. This includes package 'names' with some sort of wildcard (?, or *). - </para> - <para> - Then it iterates over all the excluded packages, appending each of those to the YUM configuration exclude list. - </para> - <para> - Now that Revisor has a very simple, flat list of package names, it uses YUM's internal matching logic 5 to get what packages in the repositories matched exactly (by name), matched (by wildcard) and did not match at all. Revisor then selects the exact matches and matches, adding them to the transaction. - </para> - </section> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving"> - <title>Dependency Resolving</title> - <indexterm> - <primary>Dependency Resolving</primary> - </indexterm> - <para> - Dependency resolving is the area where some of the efficiency Revisor can gain for you comes from. While of course there is specific reasons to do things one way, or the other, most people I speak to about Revisor, it is not very clear why, or what Revisor does in this area. First of all, there's two ways of resolving dependencies: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title>Inclusive Dependency Resolving</title> - <indexterm> - <primary>Dependency Resolving</primary> - <secondary>Inclusive</secondary> - </indexterm> - <para> - Iterate all packages in the transaction and list their requirements, then for each of those requirements, find all packages that provide a matching capability, add those packages to the transaction, and don't forget to add the requirements those packages have themselves, back into the pile of (unmet) requirements. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>Exclusive Dependency Resolving</title> - <indexterm> - <primary>Dependency Resolving</primary> - <secondary>Inclusive</secondary> - </indexterm> - <para> - Iterate all the packages and for each of the requirements found, find the best package that meets the requirement. This is also YUMs default behavior. Anaconda uses YUM during the installation, and this is the behaviour of YUM used during the installation. - </para> - </formalpara> - </listitem> - </orderedlist> - </para> - - <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Inclusive"> - <title>Inclusive Dependency Resolving</title> - <para> - Hypothetically, you could describe inclusive dependency as follows: - </para> - <para> - <screen>final_packages = [] -more_to_do = True -while more_to_do: -more_to_do = False -for package in packages: - if package in final_packages: - continue - - dependencies = find_package_dependencies() - for dependency in dependencies: - pulled_in_package = pull_in_dependency() - if pulled_in_package not in final_packages: - packages.append(pulled_in_package) - more_to_do = True</screen> - </para> - <para> - So, what does this mean? Basically, it means that if there is a requirement for a capability, all packages providing that capability are being pulled in. Now imagine package 'foo' requires capability 'web-client'. There's a number of packages providing that capability, right? So you get Firefox, lynx, elinks, konqueror, safari, Netscape, Internet Explorer, emacs, for free! All of those pull in their own dependencies also, of course. - </para> - <note> - <para> - If you catch this before it catches you, you can prevent the packages from being pulled in during dependency resolving by not making the package available in the <xref linkend="Revisor_Documentation-Appendix-Terminology-Package_Sack" /> in the first place, using the <literal>-firefox</literal> syntax in the kickstart package manifest, and setting <literal>kickstart_uses_pkgsack_excludes</literal> to 1. - </para> - </note> - <note> - <para> - You may have thought of it; pulling in packages this way may give you a package set (or <emphasis>RPM payload</emphasis>) that has conflicting packages. Imagine package <application>foo</application> requiring capability <application>bar</application>, which is provided by two packages that conflict with one another (either on explicit <literal>Conflicts:</literal> RPM header or file level). Both will be pulled in, hence disabling you to install everything (<literal>'*'</literal> or -previously- <literal>@Everything</literal> in the kickstart package manifest). - </para> - </note> - - <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Makes_Sense"> - <title>When This Makes Sense</title> - <para> - If you are composing a large distribution of which 3 million users in even so many different situations having so many different expectations and desires, you will want this behaviour, since you won't be able to determine which one of the packages for each capability someone in that group wants, and which one may not want. Or, in case of upgrades, what the system needs. Shipping them all on the same media is the best solution in these cases. - </para> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Does_Not_Make_Sense"> - <title>When This Does Not Make Sense</title> - <para> - <itemizedlist> - <listitem> - <para> - When creating installation media to be installed unattended, or to be used in conjunction with deployment strategies - </para> - </listitem> - <listitem> - <para> - When creating installation media to be upgrading PCs you have controlled from the beginning, such as in a company - </para> - </listitem> - <listitem> - <para> - Installation for a small group of users or systems - </para> - </listitem> - <listitem> - <para> - When creating minimal installation media, or media with a minimal RPM payload. - </para> - </listitem> - <listitem> - <para> - When creating installation media that is to be used with installing "Everything" in the RPM payload. - </para> - </listitem> - </itemizedlist> - </para> - </section> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Exclusive"> - <title>Exclusive Dependency Resolving</title> - <para> - Exclusive dependency resolving is what YUM does when you execute a <application>yum install</application>. Unless you've specified one of the packages satisfying any of the dependencies in the transaction, YUM is going to look up the best match for you. This results in the installation of only one package providing the requirement(s) of other packages, rather then all packages providing said requirement being installed. - </para> - <para> - As an example, imagine you install a package foo which requires capability web-client. Using exclusive dependency resolving, YUM would select one package providing the web-client capability whereas inclusive dependency resolving would include all packages providing the web-client capability. - </para> - <para> - During the installation procedure, one of the major features of installation media, anaconda is going to use YUM dependency resolving to satisfy all the dependencies. - </para> - <note> - <title>Installation Procedure !== Upgrade Procedure</title> - <para> - Note that an installation procedure is not the same as an upgrade procedure. With an installation procedure for example, you have control over the partitioning layout whereas with an upgrade procedure, you have none. More importantly, during an upgrade procedure, the (already installed) system has an existing package set which needs to be updated/upgraded and thus could possibly introduce dependency resolving problems, because of third party packages installed on the system, or because the media used to upgrade the system with does not contain the software packages needed to complete the upgrade RPM transaction. - </para> - </note> - </section> - - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Copying_Arbitrary_Files_Onto_The_Media"> - <title>Copying Arbitrary Files Onto the Media</title> - <para> - With <literal>--copy-dir</literal>, you can specify a path Revisor should copy onto the media. - </para> - <formalpara> - <title>Installation Media</title> - <para> - In the case of installation media, the path specified with <literal>--copy-dir</literal> will be copied recursively to the <filename>files/</filename> sub-directory at the root of the ISO image (or the first ISO image if you compose split media). - </para> - </formalpara> - <para> - A few use-case examples: - </para> - <para> - <itemizedlist> - <listitem> - <para> - If one kickstart profile is not enough for you to deploy the product onto your systems, create a directory that holds multiple kickstart files and specify the path to that directory using <literal>--copy-dir</literal>. The kickstart files now end up available to the installation procedures as <filename>cdrom:/files/*.ks</filename>, and can thus be used by specifying them on the kernel cmdline (<code>ks=cdrom:/files/profile1.ks</code>), or, when used in combination with <literal>--isolinux-cfg</literal> from the <xref linkend="Revisor_Documentation-Plugins-Upstream-Isolinux_Plugin" endterm="Isolinux_Plugin" />, can be added as an option in the isolinux menu. - </para> - </listitem> - <listitem> - <para> - If you have files or scripts that need to be copied onto, or run on, the installed system before it attempts to reboot and operate normally, you can use <literal>--copy-dir</literal> to make these files and scripts available during the installation and copy or execute them from either <code>%pre</code> or <code>%post</code> scripts. - </para> - </listitem> - </itemizedlist> - </para> - <formalpara> - <title>Live Media</title> - <para> - In the case of live media, the path specified with <literal>--copy-dir</literal> will be copied recursively onto the root directory (<filename>/</filename>) of the live media filesystem (which is probably loop-mounted onto <filename>/var/tmp/revisor/</filename>). - </para> - </formalpara> - <para> - If, for example, you want to copy a home directory onto the live media, and the home directory you want to copy is at <filename>/home/user1/</filename> on the composing system, you copy this directory so that the root of that new directory has a sub-directory <filename>home/</filename> which in turn contains a sub-directory <filename>user1/</filename>: - </para> - <para> - <screen>$ <userinput>mkdir -p /tmp/something/home/</userinput> -$ <userinput>cp -a /home/user1 /tmp/something/home/.</userinput> -$ <userinput>revisor [options] --copy-dir /tmp/something/</userinput></screen> - </para> - </section> - - <section id="Revisor_Documentation-Compose_Process_Details-Cleaning_Up"> - <title>Cleaning Up</title> - <para> - Revisor tends to clean up after itself by default. If a product compose succeeds, you (probably) don't need to change this default behaviour. However, by default, Revisor tends to leave the YUM cache directories untouched. This is to prevent you from having to download all the packages a second, third or more times when you run another compose. - </para> - <para> - To change this default behaviour, Revisor has an option <literal>--clean-up</literal>. The default value for this option is <literal>1</literal>, meaning Revisor will clean up it's temporary, compose-specific files, but no files that could be re-used. Specifying <literal>--clean-up=0</literal> will cause Revisor to leave everything behind and not clean anything up at all. This is most ideal for troubleshooting purposes, where one needs to examine the temporary, compose-specific files and see what went wrong. To clean up everything however, because for example you might be low on disk-space, use <literal>--clean-up=2</literal>. Revisor will then also clean up the files that could be re-used. - </para> - - <section id="Revisor_Documentation-Compose_Process_Details-Cleaning_Up-Exception-to-the-Rule"> - <title>Exception to the Rule</title> - <para> - There's one exception to the rule of cleaning up. <filename>/var/tmp/revisor/</filename>, or put more accurately, the path specified as the <code>installroot</code> in the YUM configuration file configured with the model used to compose the product, will not be cleaned up afterwards. When composing live media, this directory may still be in use as a mount-point for the live media filesystem. Removing this directory recursively in these cases would not make sense. - </para> - </section> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Configuration.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Configuration.xml deleted file mode 100644 index 9d435bf..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Configuration.xml +++ /dev/null @@ -1,280 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Configuration"> - <title>Configuration</title> - <para> - Revisor configuration can be performed using <xref linkend="Revisor_Documentation-Configuration-Files" />, or through <xref linkend="Revisor_Documentation-Configuration-Command-line_Options" />. - </para> - - <section id="Revisor_Documentation-Configuration-Files"> - <title>Configuration Files</title> - <para> - Revisor uses configuration files for a large part of it's operations. These files mostly reside in <filename>/etc/revisor/</filename>. There is two types of files Revisor uses: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title>Revisor Configuration Files</title> - <para> - Revisor configuration files, such as <filename>/etc/revisor/revisor.conf</filename>, contain information and settings unique to Revisor. A Revisor configuration file is where you specify default options, and include information on different products you want to compose. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>YUM Configuration Files</title> - <para> - YUM configuration files, such as the files in <filename>/etc/revisor/conf.d/</filename>, contain configuration for YUM. To be more precise, Revisor doesn't even handle the files (it let's YUM do so). The files in <filename>/etc/revisor/conf.d/</filename> practically contain the same information as <filename>/etc/yum.conf</filename> combined with the files in <filename>/etc/yum.repos.d/</filename> (but not exactly the same content!). - </para> - </formalpara> - </listitem> - </orderedlist> - </para> - - <section id="Revisor_Documentation-Configuration-Files-_etc_revisor_revisor.conf"> - <title><filename>/etc/revisor/revisor.conf</filename></title> - <para> - The default Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. This configuration file contains two sections: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title><literal>[revisor]</literal></title> - <para> - The global section. Options specified in this section apply to all the models defined in this configuration file. - </para> - </formalpara> - <para> - See also: <xref linkend="Revisor_Documentation-Configuration-Global_and_Model_Configuration" /> - </para> - </listitem> - <listitem> - <formalpara> - <title><literal>[<replaceable>model</replaceable>]</literal></title> - <para> - Model configuration. One section per <xref linkend="Revisor_Documentation-Appendix-Terminology-model" />. - </para> - </formalpara> - <para> - See also: <xref linkend="Revisor_Documentation-Configuration-Global_and_Model_Configuration" /> - </para> - </listitem> - </orderedlist> - </para> - <para> - Model sections basically define a single product. Amongst other things, the distribution name, release version, architecture for the product to be composed and what YUM configuration file to use, are (often) defined on a per-model basis. There is a large number of settings available for models, and they are all related to how the product is going to look like. The product name, the location of the RPM payload for installation media, the ISO label, the YUM configuration file to use, are all model settings. - </para> - <para> - Using models, you can reproduce the outcome of the compose process, a <emphasis>product</emphasis>, simply by not changing the model configuration anymore. If you want something different, you can just add another model section, and name it differently. - </para> - <para> - To see what models are available with the Revisor standard package, use: - </para> - <para> - <screen>$ <userinput>revisor --list-models</userinput></screen> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Files-_etc_revisor_conf.d_"> - <title><filename>/etc/revisor/conf.d/</filename></title> - <para> - The default YUM configuration files used by Revisor. In a model configuration section, the <literal>main =</literal> setting points to one of the YUM configuration files in <filename>/etc/revisor/conf.d/</filename> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Files-Updates"> - <title>Updates to Configuration Files</title> - <para> - The Revisor packages are not allowed to overwrite files in <filename>/etc/</filename>, and they should thus not do so. If an update to Revisor is installed on your system, files with the extension <literal>.rpmnew</literal> may be created --if you had changed anything in the file before applying the update. Since this world isn't perfect, configuration errors may exist in the configuration files shipped with Revisor. Please pay close attention to updates to these configuration files by examining the <literal>.rpmnew</literal> files. - </para> - <para> - You can use any file location (not just <filename>/etc/revisor/</filename>) for your own custom configuration. - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Files-Changing_Configuration_Files"> - <title>Changing Configuration Files</title> - <para> - If you are creating your own models off of the ones that ship with Revisor itself, please consider using an alternative configuration file (a file other then <filename>/etc/revisor/revisor.conf</filename>, or copy the original file for safekeeping. This way, you can always return to a working, sample configuration file and test whether it is Revisor causing errors, or configuration mistakes. - </para> - </section> - - </section> - - <section id="Revisor_Documentation-Configuration-Global_and_Model_Configuration"> - <title>Global and Model Configuration</title> - <para> - The default Revisor configuration file, <filename>/etc/revisor/revisor.conf</filename> consists of multiple sections (the file is in .INI format). One is the <literal>[revisor]</literal> global section, where you specify configuration options that apply to each other section or <xref linkend="Revisor_Documentation-Appendix-Terminology-model" />. - </para> - <para> - The options specified in the global and model configuration sections apply to the Revisor compose in the following order: - </para> - <para> - <orderedlist> - <listitem> - <para> - The options from the global section are read, tested and set. - </para> - </listitem> - <listitem> - <para> - The options from a model section are read, tested and set, regardless of whether the global section had caused the setting to be set to a certain value already. - </para> - </listitem> - </orderedlist> - </para> - <para> - For example, if you know all the models in a configuration file are optical live media products, the configuration sections could look like the following: - </para> - <para> - <screen>[revisor] -# Optical live media for all models -media_live_optical = 1 - -[model1] -main = /etc/revisor/conf.d/revisor-model1.conf -description = The model1 product -architecture = i386 -# This is already configured in the global section of -# this configuration file and can thus be removed. -#media_live_optical = 1</screen> - </para> - <note> - <title>When Running the GUI</title> - <para> - Note that when running Revisor in Graphical User Interface mode, you can still change a lot of the settings supplied by Revisor through the configuration files loaded. When you are running Revisor in GUI mode, the configuration files supply the defaults. - </para> - </note> - </section> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories"> - <title>YUM Repository Configuration</title> - <para> - The files in <filename>/etc/revisor/conf.d/</filename> are YUM configuration files. Revisor directs YUM to use these files during the compose process, and does not handle these files itself. This chapter lists a few tips and tricks. - </para> - <para> - Because these files are YUM Configuration files, you can configure anything that YUM supports. See <application>man yum.conf</application> for more details. - </para> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories-releasever_and_basearch"> - <title>$releasever and $basearch</title> - <para> - When configuring a repository URL, make sure you do not use <replaceable>$releasever</replaceable> or <replaceable>$basearch</replaceable> variables. Since Revisor allows cross-composing distributions between different versions of the operating system, as well as different architectures, these variables need to be expanded to the value intended. - </para> - <para> - See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories-Using_a_Local_Mirror"> - <title>Using a Local Mirror</title> - <para> - If you have a local mirror of Fedora, you can use the <literal>baseurl</literal> configuration directive in each repository configuration section to tell YUM to use the local mirror. - </para> - <para> - Optionally, you can also disable the <literal>mirrorlist</literal>, preferably by outcommenting it, so that YUM will only use the local mirror. - </para> - <para> - The default <literal>baseurl</literal> uses <literal>http://download.fedoraproject.org/</literal>. This location may or may not be suitable for you. If you have a local mirror, you might want to change this setting here, or add your mirror to Fedora Project's Mirrorlist. - </para> - <note> - <title>Adding your local mirror to the Mirrorlist</title> - <para> - You can add your local mirror to the Mirrorlist, so that the Fedora Project mirrorlist redirects you to your local mirror. Additionally, systems in your local network(s) will be redirected to the local mirror. The local mirror does not have to be a public mirror in order to do so. See <ulink url="http://admin.fedoraproject.org/mirrormanager/" /> for more details. - </para> - </note> - <para> - Set each <literal>baseurl</literal> to the location of the repository on the local mirror. - </para> - <para> - See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories-Using_Local_Files"> - <title>Using Local Files</title> - <para> - If you have the repositories on your local filesystem, configure a <literal>baseurl</literal> of <filename>file://<replaceable>/path/to/repository/</replaceable></filename>. - </para> - <note> - <title>Make sure to supply the correct path</title> - <para> - Make sure to supply the correct path to the repository. <filename>file://</filename> is the "<emphasis>protocol</emphasis>" for the location, and the location is <filename><replaceable>/path/to/repository/</replaceable></filename>. Put together, you have <emphasis>three</emphasis> slashes. - </para> - </note> - <para> - See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories-Using_a_DVD"> - <title>Using a DVD</title> - <para> - A DVD does not contain enough packages to rebuild the installer images. If you are using a DVD and you want to rebuild the installer images, you will need to have a network connection and a mirror you can reach. - </para> - <para> - There is a list of required packages, but since the packages change per release and may change in the middle of the release cycle as well, we cannot hand you a list that just works. - </para> - <para> - See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories-Adding_Third_Party_Repositories"> - <title>Adding Third Party Repositories</title> - <para> - When adding a third party repository, make sure you add the correct release version as well as architecture to the Revisor YUM configuration file. Verify the location for the <literal>baseurl</literal> and/or <literal>mirrorlist</literal> you configure manually or through YUM. Make sure you expand any <literal>$releasever</literal>, <literal>$basearch</literal> and <literal>$arch</literal> variables. - </para> - <para> - See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories-Creating_Your_Own_Repository"> - <title>Creating Your Own Repository</title> - <para> - Creating your own repository is relatively simple. You take a directory, dump some RPM packages in it, and run <application>createrepo</application>. See <literal>man createrepo</literal> for more information. - </para> - <para> - People often wonder how Revisor handles comps.xml group files. - </para> - <para> - When you create your own repository, follow the directions in <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Adding_Third_Party_Repositories" /> to add the repository configuration to Revisor's YUM configuration, since your own repository is a third party repository as well. - </para> - <para> - See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting"> - <title>Testing & Troubleshooting the YUM Configuration</title> - <para> - Before you use the (modified) configuration file, take it for a test run. - </para> - </section> - - </section> - - <section id="Revisor_Documentation-Configuration-Configuring_A_Proxy"> - <title>Configuring A Proxy Server</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Configuration-Command-line_Options"> - <title>Command-line Options</title> - <para> - With the command-line options available, you can configure options that either override what is in the configuration file or have simply not been configured using the configuration file. With the default configuration files that come with the <application>revisor-cli</application> package for example, no media products have been pre-configured in the default section. In the <application>revisor-unity</application> package however, some default configuration has been applied so that Fedora Unity Re-Spins actually create CD, DVD and Rescue ISO images as well as the Installation Tree and include the sources. - </para> - <para> - Only some configuration options have CLI parameters. Use <application>revisor --help</application> to see a complete list of configuration options you can supply on the command line. - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Development.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Development.xml deleted file mode 100644 index 02407c1..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Development.xml +++ /dev/null @@ -1,220 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Development"> - <title>Development</title> - <para> - This chapter sheds some light on development of Revisor, such as different branches and maintenance policies, versioning schemas, etcetera. - </para> - <para> - This part of the documentation relies on whether you have <application>sudo</application> set up properly. If you have not, you're on your own. - </para> - - <section id="Revisor_Documentation-Development-Running_Revisor_from_Source"> - <title>Running Revisor from Source</title> - <para> - The latest code in GIT can be built into a RPM you can install but one of the advantages of having the complete source tree is that you can run it directly from that source tree so that when you pull in the next updates you do not have to rebuild the RPM. Note that we do not bump the version number for every little change we make, and as such the RPM built does not allow you to use <literal>rpm -Uvh</literal> or <literal>rpm -Uvh --oldpackage</literal>. Of course, Revisor's Makefiles also allow <application>make install</application>, but that leaves a number of unmanaged files on your computer you would have to track down manually in order to remove Revisor completely. - </para> - <warning> - <title>Cannot have Revisor RPMs installed</title> - <para> - When running revisor from within the source tree, you cannot have any of the Revisor packages installed. Having Revisor RPM packages installed regardless will mess up the GIT repository or source tree. - </para> - </warning> - <para> - To run Revisor from within the source tree, checkout the master branch, and run the <filename>./switchhere</filename> script: - </para> - <para> - <screen>$ <userinput>./switchhere</userinput></screen> - </para> - <para> - The <filename>./switchhere</filename> script does the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Symlink <filename>/etc/revisor/</filename> to <filename><replaceable>$PWD</replaceable>/conf/</filename> so that <filename>/etc/revisor/revisor.conf</filename>, the primary configuration file, and <filename>/etc/revisor/conf.d/</filename>, the configuration directory, are valid (the symlink causes the actual file and directory to be found in <filename><replaceable>$PWD</replaceable>/conf/</filename>) - </para> - </listitem> - <listitem> - <para> - Create the <filename>/usr/share/revisor/</filename> directory so that a couple of symlinks can be created from within that directory: - </para> - </listitem> - <listitem> - <para> - In Revisor 2.1.0 (development version in branch master), this includes: - </para> - <para> - <itemizedlist> - <listitem> - <para> - <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/revisor/modgui/glade/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/revisor/modgui/glade/pixmaps/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - <listitem> - <para> - In Revisor 2.0.5 (branch F-7, F-8 or EL-5), this includes: - </para> - <para> - <itemizedlist> - <listitem> - <para> - <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/glade/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/glade/pixmaps/</filename> - </para> - </listitem> - <listitem> - <para> - <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - <listitem> - <para> - In Revisor 2.1.0, also create symlinks from within the appropriate <filename>/usr/share/man/man<replaceable>$x</replaceable>/</filename> directories to the source for these man pages in <filename><replaceable>$PWD</replaceable>/doc/</filename>. - </para> - </listitem> - </itemizedlist> - </para> - <para> - From this moment on, you should be able to run: - </para> - <para> - <screen>$ <userinput>./revisor.py</userinput></screen> - </para> - <note> - <title>Root privileges required</title> - <para> - Note that revisor needs root privileges to run, and that you'll need to sudo or su-c to gain those. Use here whatever you find the most convenient; Revisor though should have a nice error message when run without those privileges. - </para> - </note> - - <section id="Revisor_Documentation-Development-Running_Revisor_from_Source-Required_Packages"> - <title>Installing the Required Packages</title> - <para> - To be able to run Revisor from within the source tree, you'll need to install the required packages for each component, of course. - </para> - <para> - To get a current list of those packages, use: - </para> - <para> - <screen>$ <userinput>rpmquery --specfile --qf="%{REQUIRES}\n" revisor.spec | sort | uniq | xargs -n 1 repoquery --requires --alldeps --resolve</userinput></screen> - </para> - </section> - - </section> - - <section id="Revisor_Documentation-Development-Building_Revisor_Packages"> - <title>Building Revisor Packages</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Development-Tickets"> - <title>Tickets</title> - <para> - bugzilla, trac - </para> - </section> - - <section id="Revisor_Documentation-Development-Adding_A_New_Spin"> - <title>Adding a new spin or remix</title> - <para> - <orderedlist> - <listitem> - <para> - Add the appropriate models in the appropriate configuration file for Revisor. - </para> - </listitem> - <listitem> - <para> - Add the appropriate configuration file to the appropriate automake Makefile - </para> - </listitem> - <listitem> - <para> - Run autoreconf && ./configure && make rpm to verify the rpm building - </para> - </listitem> - <listitem> - <para> - Create the model's YUM configuration files with the following repositories: - </para> - <para> - <itemizedlist> - <listitem> - <para> - fedora, enabled, pointing to Everything - </para> - </listitem> - <listitem> - <para> - fedora-source, disabled, pointing to Everything - </para> - </listitem> - <listitem> - <para> - fedora-updates, enabled, pointing to the updates repository - </para> - </listitem> - <listitem> - <para> - fedora-updates-source, disabled, pointing to the updates repository - </para> - </listitem> - <listitem> - <para> - anaconda-updates, enabled, pointing to the anaconda updates repository - </para> - </listitem> - <listitem> - <para> - anaconda-updates-source, disabled, pointing to the ananconda updates repository - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - </orderedlist> - </para> - </section> - - <section id="Revisor_Documentation-Development-Versioning_Schema"> - <title>Versioning Schema</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Development-Release_Procedure"> - <title>Release Procedure</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Features.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Features.xml deleted file mode 100644 index 6583398..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Features.xml +++ /dev/null @@ -1,175 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Features"> - <title>Features</title> - <para> - Revisor allows you to build and customize your own Remix, Re-Spin, Spin or even your own distribution, based on Fedora and derivative distributions such as Red Hat Enterprise Linux and CentOS. - </para> - <para> - Revisor builds installation media, live media, installation trees, cobbler distro's and profiles, virtualization images and more. - </para> - - <section id="Revisor_Documentation-Features-Installation_Media"> - <title>Installation Media</title> - <para> - Installation media is what you use to install a system with. The installation media composed will allow you to go through the installation process, answering a number of questions (either manually or through kickstart), and ends up in a system running the distribution you install. - </para> - <para> - Composing installation media using the Revisor GUI allows you to choose the media (CD, or DVD), the packages to be included on the media (also called <emphasis>RPM payload</emphasis>). - </para> - <para> - Using the command-line interface, Revisor also allows you to choose DVD Duallayer and single- or dual-layer Bluray. - </para> - </section> - - <section id="Revisor_Documentation-Features-Installation_Trees"> - <title>Installation Trees</title> - <para> - Installation trees are typically used in environments where a distribution needs to be deployed over multiple systems, or is very volatile. Installation trees are often made accessible through HTTP or FTP protocols, in one place, and do not have as much overhead (in creating .iso files, and burning those to optical media to distribute them). - </para> - </section> - - <section id="Revisor_Documentation-Features-Live_Media"> - <title>Live Media</title> - <para> - Live media often is a perfect showcase for an Operating system, Desktop Environment or any other thing you want to show. Also, since Live media is read-only, live media perfectly allows for a kiosk system, a system that may change while it's running, but restores all original settings when rebooted. - </para> - <para> - Live media is also installable. You start out with a system and boot it from live media, then choose to install the live media. This however is inferior to real installation media, but is convenient if you happen to like what you see when running from live media. - </para> - </section> - - <section id="Revisor_Documentation-Features-Reproducibility"> - <title>Reproducibility</title> - <para> - Media composed with Revisor is extremely reproducible. Using <literal>kickstart_exact_nevra</literal>, you can even select specific versions of packages to be included on the product. - </para> - </section> - - <section id="Revisor_Documentation-Features-Consistency"> - <title>Consistency</title> - <para> - When composing different types of media, such as CDs and DVDs, Revisor composes these discs in one run, making the different media completely consistent. <application>pungi</application> would require you to run twice, once for CDs, and once for DVDs. This is because <application>pungi</application> uses the <literal>part / <replaceable><size></replaceable></literal> kickstart configuration directive to set the maximum size of the media, and has no option to override the size on the command-line, nor to compose a certain set of media (it all depends on the size). - </para> - </section> - - <section id="Revisor_Documentation-Features-Flexibility"> - <title>Flexibility</title> - <para> - Over the years, Revisor has been adopted to serve a large number of use-cases, where use-cases stretch from media being composed as efficient as possible, as robust as possible, specific deployment needs and expectations, and to match the Fedora Project Release Engineering tools' behaviour. All this allows you to configure a lot, and thus customize a lot, making Revisor more of a flexible framework. - </para> - </section> - - <section id="Revisor_Documentation-Features-Graphical_User_Interface"> - <title>Graphical User Interface</title> - <para> - Revisor has a Graphical User Interface or GUI, in addition to the Command Line Interface or CLI, which makes Revisor more accessible to users then the other tools, which are CLI only. Most people only know of Revisor through the GUI, and may think there is no CLI to Revisor. Only when it comes down to many of the additional features that Revisor has, and that do not fit in a simplified GUI, one gets down with it using the CLI. - </para> - </section> - - <section id="Revisor_Documentation-Features-Open_Development_Community"> - <title>Open Development Community</title> - <para> - Revisor has one of those old-fashioned Free and Open Source Software development communities, allowing anyone to make a contribution to Revisor. In fact, Revisor has not bounced a single patch since the project started. Therefor, it improves faster then any of the other compose tools, and is better adaptible to your needs and expectations, because unlike the other utilities, Revisor is not limited to use-cases that apply to Fedora Project Release Engineering. - </para> - </section> - - <section id="Revisor_Documentation-Features-Plugin_System"> - <title>Plugin System</title> - <para> - Revisor has a plugin system so that you can easily extend Revisor. This plugin system gives you full control over the Revisor procedures, and hands you off anything Revisor knows about the compose process. There's are multiple plugins available from upstream as well. To give you an example, the ability to replace <filename>isolinux.cfg</filename> after the compose is done, is a plugin. See <xref linkend="Revisor_Documentation-Plugins" /> for more information. - </para> - - <para> - Current plugins included with Revisor include: - </para> - <para> - <itemizedlist> - <listitem> - <para> - <xref linkend="Revisor_Documentation-Plugins-Upstream-Cobbler_Plugin" /> - </para> - </listitem> - <listitem> - <para> - <xref linkend="Revisor_Documentation-Plugins-Upstream-Isolinux_Plugin" /> - </para> - </listitem> - <listitem> - <para> - <xref linkend="Revisor_Documentation-Plugins-Upstream-Rebrand_Plugin" /> - </para> - </listitem> - <listitem> - <para> - <xref linkend="Revisor_Documentation-Plugins-Upstream-Reuse_Installer_Images_Plugin" /> - </para> - </listitem> - </itemizedlist> - </para> - </section> - - <section id="Revisor_Documentation-Features-Extraneous_Debugging"> - <title>Extraneous Debugging</title> - <para> - Revisor has extraneous debugging, which enables you, as well as the supporters and Revisor's developers, to trace down what happens exactly, and where anything might go wrong. - </para> - </section> - - <section id="Revisor_Documentation-Features-Using_YUM_Configuration_Files"> - <title>Using YUM Configuration Files</title> - <para> - Revisor uses YUM configuration files, where everyone else is not. With using YUM configuration files however, the control you have is nearly limitless. With all the features in YUM already, using it's configuration file format and letting YUM itself work with those allows Revisor to do a lot of cool things without doing anything itself: - </para> - <para> - <orderedlist> - <listitem> - <formalpara> - <title>Excluding packages from repositories</title> - <para> - Excluding packages from repositories means a great deal. Not having them exist in the <xref linkend="Revisor_Documentation-Appendix-Terminology-Package_Sack" /> ensures the package will not end up in the product. This may be what you want for maybe just a few, or maybe an awful lot of packages. - </para> - </formalpara> - <para> - Using the alternative configuration file format, kickstart, in use by every other compose tool, and the <literal>repo</literal> configuration directive that is available with kickstart, you can exclude packages using the <literal>--exclude=</literal> parameter to the <literal>repo</literal> configuration directive. However, that parameter does not allow wildcard matches. - </para> - </listitem> - <listitem> - <formalpara> - <title>Including only a certain (set of) package(s)</title> - <para> - Including only a certain package, or certain set of packages is valuable when a lot of packages exist in the repository configured, but you only need one or two. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>Concurrent use of baseurl(s) and the mirrorlist</title> - <para> - Like during normal YUM operations, the baseurl(s) and the mirrorlist configured for a repository are used concurrently. This is not possible with the kickstart configuration directive <literal>repo</literal>, which takes either <literal>--baseurl</literal> or <literal>--mirrorlist</literal>, but not both. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>Repository priorities</title> - <para> - Settings available with YUM are available within Revisor as well, like repository priorities. Using repository priorities, you can have YUM decide to pull a package from the repository with a higher priority (a lower priority number) rather then a repository with a lower priority. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title>YUM Plugins</title> - <para> - YUM plugins, such as <application>yum-fastestmirror</application>, <application>yum-fedorakmod</application>, are available, giving you even more control over the behaviour of YUM. - </para> - </formalpara> - </listitem> - </orderedlist> - </para> - </section> -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml deleted file mode 100644 index 489d42a..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml +++ /dev/null @@ -1,54 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Frequently_Asked_Questions"> - <title>Frequently Asked Questions</title> - <para> - para - </para> - - <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-How_Does_Revisor_Handle_Comps"> - <title>How Does Revisor Handle Comps?</title> - <para> - para - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-What_Are_Installer_Images"> - <title>What Are Installer Images?</title> - <para> - para - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Pungi"> - <title>What is the relationship between Revisor and Pungi?</title> - <para> - Where pungi builds a bunch of RPMs into ISO images and installation trees through one single procedure, perfect for Release Engineering on something like the Fedora Project, Revisor does it different entirely. - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Livecd-tools"> - <title>What is the relationship between Revisor and livecd-tools?</title> - <para> - Revisor depends on livecd-tools for the composing of live media. Creating the filesystem to install the packages to, turning that image file into a SquashFS file, and applying the settings inside the chroot. - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-Why_Rebuild_Installer_Images"> - <title>Why Rebuild Installer Images?</title> - <para> - para - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-How_do_I_create_an_updates.img"> - <title>How do I create an updates.img?</title> - <para> - para - </para> - </formalpara> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Installation.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Installation.xml deleted file mode 100644 index 9997088..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Installation.xml +++ /dev/null @@ -1,104 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Installation"> - <title>Installation</title> - <para> - This chapter contains the installation instructions for Revisor. - </para> - - <section id="Revisor_Documentation-Installation-Packages"> - <title>Packages</title> - <para> - You can install Revisor using RPM packages from the repositories already configured on your system. - </para> - - <formalpara id="Revisor_Documentation-Installation-Packages-revisor"> - <title><application>revisor</application></title> - <para> - Shorthand package for the Revisor GUI. - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Installation-Packages-revisor-cli"> - <title><application>revisor-cli</application></title> - <para> - The CLI version of Revisor. This package is always installed, as it contains the Python code for Revisor's core. Installing just this package will give you the command-line version of Revisor, and prevents the graphical dependencies from the <xref linkend="Revisor_Documentation-Installation-Packages-revisor-gui" /> package to be installed as well. - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Installation-Packages-revisor-gui"> - <title><application>revisor-gui</application></title> - <para> - The GUI version of Revisor. This is the actual package containing the Graphical User Interface, as opposed to <xref linkend="Revisor_Documentation-Installation-Packages-revisor" />. Depends on <xref linkend="Revisor_Documentation-Installation-Packages-revisor-cli" />, and thus also installs the command-line version of Revisor. - </para> - </formalpara> - - <section id="Revisor_Documentation-Installation-Packages-YUM-RHEL"> - <title>Red Hat Enterprise Linux 5 or higher</title> - <para> - On Red Hat Enterprise Linux 5 or higher, and derivatives, install the Extra Packages for Enterprise Linux (EPEL) repository. - </para> - <para> - Then, give the following command: - </para> - <para> - <screen># <userinput>yum install revisor</userinput></screen> - </para> - </section> - - <section id="Revisor_Documentation-Installation-Packages-YUM-Fedora"> - <title>Fedora 7 or higher</title> - <para> - On Fedora 7 or higher, and derivatives, no additional repository configuration is required. - </para> - <para> - Give the following command: - </para> - <para> - <screen># <userinput>yum install revisor</userinput></screen> - </para> - <note> - <title>About EOL Releases</title> - <para> - Please bear in mind that Fedora releases that are past the point of End-Of-Life, approximatly 13 months after the initial release, are not supported anymore for use with Revisor. Also, the version of Revisor running on these EOL versions of Fedora are not supported anymore. - </para> - </note> - </section> - - </section> - - <section id="Revisor_Documentation-Installation-The_Latest_And_Greatest"> - <title>The Latest and Greatest</title> - <para> - The latest and greatest is available from GIT, at <ulink url="git://git.fedorahosted.org/revisor" />. To clone this repository, use: - </para> - <para> - <screen>$ <userinput>git clone git://git.fedorahosted.org/revisor/</userinput></screen> - </para> - <para> - Using the GIT clone, you have the several options to start using the latest and greatest: - </para> - <formalpara> - <title>Running directly from the source</title> - <para> - You can run directly from within the source tree. See <xref linkend="Revisor_Documentation-Development-Running_Revisor_from_Source" /> for more information on how to do so. - </para> - </formalpara> - <warning> - <title>Installed packages and running from source</title> - <para> - Do not run Revisor from source while RPM packages have been installed. Files managed by a package will get created, moved and removed when using Revisor's source tree, and updates to the installed RPM packages will destroy these changes. - </para> - </warning> - <formalpara> - <title>Building your own packages</title> - <para> - You can create your own packages, so that you have all the benefits of RPM. See <xref linkend="Revisor_Documentation-Development-Building_Revisor_Packages" /> for more information on how to do so. - </para> - </formalpara> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Introduction.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Introduction.xml deleted file mode 100644 index 465fbf2..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Introduction.xml +++ /dev/null @@ -1,71 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Introduction"> - <title>Introduction</title> - <para> - Revisor is a community product by Fedora Unity. Amongst other features, it allows the creation of installation media and live media in the easiest possible manner, through a click-and-go GUI. This chapter gives some insight on how and why Revisor was born, and how the product evolved since. - </para> - - <section id="Revisor_Documentation-Introduction-History_Of_Revisor"> - <title>History of Revisor</title> - <para> - Revisor development started in December 2006, during the Fedora 7 development cycle, in which -you might recall- the Fedora Core repository, maintained by Red Hat, and Fedora Extras repository, mostly maintained by the community, were merged into one large repository being maintained by both community members as well as Red Hat employees -which are mostly community members hired by Red Hat -so community altogether. Before then Red Hat employees maintained Fedora Core -as the set of packages upstream for Red Hat's Enterprise product- and the community maintained a repository with additional software; Fedora Extras. Red Hat composed the Fedora distribution every once in a while, but the merge introduced the possibility for packages that were in Fedora Extras to be included in the main distribution, and for the community to also (co-)maintain the (former) Fedora Core packages that originally made up the distribution. - </para> - <para> - In addition to this huge merge of packages, Red Hat employees were also able to release the entire build process to the community, meaning that from the moment the source is committed up and until the release is announced, the entire process is open. Not that is was all behind closed doors or proprietary or anything, the community just couldn't really play with it as much. We now have koji (build system), mash (repository compose from build system products), bodhi (updates release system), livecd-tools (compose tool for live media) and pungi (compose tool for installation media). - </para> - <para> - Composing media was an obscure process up and until the moment these tools exposed the best way to compose (a set of) installation media. Fedora Unity had been building and releasing so-called Re-Spins1 regularly, but they were built using a not-so-very intelligent bash script. Like hundreds if not thousands of other parties that needed to build their own media one way or the other, the entire process was based on the best educated guess of what should happen. Luckily, in the FOSS world an educated guess is often a very good guess, despite the fact that one keeps learning even years after the original engagement. - </para> - <para> - When in December 2006 the compose tools hit a stage in which they were released to the public, Fedora Unity was eager to get these tools and study them and use them for composing their Re-Spins. Up and until then, Re-Spins were composed with the aforementioned bash script that didn't do much but trigger the appropriate commands in a sequence; There wasn't any dependency resolving between the packages included nor did we know exactly how a release was supposed to be composed -it was our educated guess of how it could happen. Although it often led to success, we've had many, many failed Re-Spins as well. With a handful of volunteers, you can imagine the amount of frustration that might give. Fedora Unity was eager to improve their Re-Spin process. - </para> - <para> - So, early February 2007, a number of Fedora Unity members attended “FUDCon 2007” in Boston, and presented a working GUI front-end to livecd-tools and pungi enabling regular users to also re-compose or re-spin the installation media and live media they had been getting from the Fedora Project. Revisor at this point just made it “as easy as possible”. Besides the possibilities of pungi and livecd-tools themselves, the wizard Revisor had apparently was very, very useful to mere mortals. From that point on, things took off. - </para> - <para> - Fedora Unity decided Revisor could accomplish more then just being a front-end to existing compose tools and enable someone to tweak a lot of settings as well. In March 2007, Revisor was rebuild from the ground up in March 2007 to allow a more flexible process, more dependent on the configuration directives it was given and less so on the processes of the existing tools. When in San Diego at the Red Hat Summit (early May 2007), Robert 'Bob' Jensen and Jonathan Steffan gave a presentation on “Customizing Fedora”, the responses were amazing. Since then Revisor has evolved from a front-end to existing tools to the complete compose tool it is today, with lots of configuration options for specific use-cases. - </para> - <para> - For users, Revisor is particularly useful because it has a GUI front-end wizard, which, with the defaults settings, will just succeed in getting a user the media he/she wants. If a user decides he needs little adjustment of the media, the GUI allows for selecting the most common options. If a user decides he needs some less common adjustments, the configuration options gives him very granular control -and as long as the documentation on all the options is sufficient, users will be able to make those less common adjustments. - </para> - <para> - For administrators on the other hand, Revisor is the tool that gives so much granular control over what happens, that it can serve almost every specific use-case. In this aspect, Revisor could potentially replace the compose tools administrators have been developing themselves with a consistent and flexible program flow. - </para> - <para> - This document should enable you to study the process of composing installation and live media, and comprehend the logic Revisor adds to that process. - </para> - </section> - - <section id="Revisor_Documentation-Introduction-The_Installation_Media_Challenge"> - <title>The Installation Media Challenge</title> - <para> - When Fedora Unity first started doing these so-called Re-Spins, the challenge ahead could maybe be explained like this: - </para> - <para> - <emphasis>When a user downloads a Fedora release and installs the distribution, the user will need to download and install a number of updates. The “older” the release becomes, the more updates will be available, and the greater the total download size of these updates the user will need to download on top of the download size of the original release media.</emphasis> - </para> - <para> - “older” is in quotes on purpose, because really for an operating system -or “distribution” if you will- being released every 6 months, “old” is quite a relative concept. The number of updates available however, at any given time during the release cycle, may range from 0 right after the release (which has never happened before), to the total amount of packages installed on the user's system (often over 2000). You can imagine the size of these updates ranging from 0 MB to an astonishing 2GB(!), only 6 months after the initial release. - </para> - <para> - Some of us do not have the bandwidth capacity or enough data transfer quota to download this many extra, rather useless bits. In addition, some of us do not have an Internet connection at all, and thus benefit getting the updates from Re-Spins directly. - </para> - <para> - The use of updates in Re-Spins has several more beneficial side-effects, which we'll explain in more detail later on in this document. Long story short; If for some reason the software used to compose the media (the release) with does not work for your hardware or your specific needs, updated software incorporated in the composed installer images might resolve that problem. - </para> - <para> - This is the original challenge the Fedora Unity team resolved a long time ago, and is at the base of what Revisor does nowadays. - </para> - </section> - - <section id="Revisor_Documentation-Introduction-The_Live_Media_Challenge"> - <title>The Live Media Challenge</title> - <para> - Back in the day Fedora Core 5 was the most recent release, Fedora Unity created so-called live media using Kadischi. In that time, live media could only have a read-only root file system and was not as feature-rich as live media is today. However, just before Revisor came to life, two applications were developed; pungi for creating installation media, and livecd-tools for creating live media. These two applications did their work well; The media composed for a release, including many different custom live media spins were, and still are, created with these tools. Immediately, the Revisor developers set themselves a target to provide a single interface to both of those tools. - </para> - </section> - -</chapter> diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Plugins.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Plugins.xml deleted file mode 100644 index adcca82..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Plugins.xml +++ /dev/null @@ -1,131 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Plugins"> - <title>Plugins</title> - <para> - para - </para> - - <section id="Revisor_Documentation-Plugins-Upstream"> - <title>Upstream Plugins</title> - <para> - Plugins available from upstream, maintained by upstream - </para> - - <section id="Revisor_Documentation-Plugins-Upstream-Cobbler_Plugin"> - <title>Cobbler Plugin</title> - <para> - The Cobbler plugin is able to put the product composed into a Cobbler environment, by handing off the built product to the existing Cobbler infrastructure as a <emphasis>distro</emphasis>, and creating a <emphasis>profile</emphasis>. - </para> - <para> - Using this module, one can automatically import the Revisor product into a Cobbler environment, and immediately use the new Cobbler <emphasis>profile</emphasis> to start deploying or automated testing, maybe. - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Composer_Plugin"> - <title>Composer Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Delta_Plugin"> - <title>Delta Plugin</title> - <para> - A small change to a ISO image does not require you to download the complete ISO image if you have a copy of the old ISO image. - </para> - <note> - <title>Only applicable to (...)</title> - <para> - The generation of Delta ISO images is only applicable to situations in which the ISO image does not contain SquashFS images. SquashFS images are smaller, but all SquashFS images are unique. Since the Delta principle is based on similarities, and no two SquashFS images are alike, creating a Delta on two ISO images containing SquashFS images will lead to a Delta pratically the same size as the SquashFS image. For Live Media that compresses the ext3 filesystem image into a SquashFS image, since that SquashFS image is probably over 97% of the size of the ISO image, creating Delta images for compressed Live Media does not make sense. For installation media however, most RPMs would be similar as well as (potentially) the installer images. - </para> - </note> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-GUI_Plugin"> - <title>GUI (Graphical User Interface) Plugin</title> - <para> - Yes, the Graphical User Interface for Revisor is actually a plugin. - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-HUB_Plugin"> - <title>HUB Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Isolinux_Plugin"> - <title>Isolinux Plugin</title> - <titleabbrev id="Isolinux_Plugin">Isolinux Plugin</titleabbrev> - <para> - The isolinux plugin adds the <literal>--isolinux-cfg</literal> command-line option to Revisor. Specify a file here, and the original <filename>isolinux.cfg</filename> that is built as part of the compose process is replaced by the <filename>isolinux.cfg</filename> specified. - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Jigdo_Plugin"> - <title>Jigdo Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Mock_Plugin"> - <title>Mock Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Rebrand_Plugin"> - <title>Rebrand Plugin</title> - <para> - The rebrand plugin hooks in to Revisor at several different stages. The goal of this plugin is to ensure no trademarked packages end up on the media. Trademarked packages may include <application>fedora-logos</application>, <application>redhat-logos</application>, and so forth. - </para> - <para> - The plugin adds a <literal>--rebrand</literal> option, to which you can specify the name of your new product. When rebranding Fedora to Omega for example, specifying <literal>--rebrand Omega</literal> would be sufficient to make sure the product does not have any Fedora trademarks. - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Reuse_Installer_Images_Plugin"> - <title>Reuse Installer Images Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Server_Plugin"> - <title>Server Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-Virtualization_Plugin"> - <title>Virtualization Plugin</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Plugins-Upstream-WUI_Plugin"> - <title>WUI (Web-based User Interface) Plugin</title> - <para> - para - </para> - </section> - - </section> - - <section id="Revisor_Documentation-Plugins-Writing_Your_Own"> - <title>Writing Your Own Plugins</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Testing.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Testing.xml deleted file mode 100644 index 2450faf..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Testing.xml +++ /dev/null @@ -1,173 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Testing"> - <title>Testing</title> - <para> - The following test cases describe different types of testing a new Revisor release. - </para> - - <section id="Revisor_Documentation-Testing-Simple_Test_Cases"> - <title>Simple Test Cases</title> - <para> - This section has a few simple test cases ensuring configuration shipped with Revisor works as anticipated. - </para> - - <section id="Revisor_Documentation-Testing-Simple_Test_cases-Packages"> - <title>Packages</title> - <para> - Install the <application>revisor-cli</application>: - </para> - <para> - <screen># <userinput>yum --enablerepo=updates-testing install revisor</userinput></screen> - </para> - <para> - Installed are all dependencies for the Revisor CLI interface. Make sure <application>spin-kickstarts</application> is installed, a package for sample kickstarts. - </para> - <para> - Starting Revisor as follows should not show any error messages related to Revisor attempting to start up it's GUI interface: - </para> - <para> - <screen># <userinput>revisor</userinput></screen> - </para> - - <formalpara> - <title>Configuration Files</title> - <para> - The following configuration files should exist: - </para> - </formalpara> - <para> - <itemizedlist> - <listitem> - <para> - <filename>/etc/revisor/revisor.conf</filename> - </para> - </listitem> - </itemizedlist> - </para> - <para> - Each section should have a configuration file listed as <literal>main</literal>. - </para> - <para> - And, of course, every configuration file listed in each section. In this case, the following snippet is easy enough: - </para> - <para> - <screen>$ <userinput>i=0; \ -configfiles="`grep ^main /etc/revisor/revisor.conf | \ - sed -r -e 's/^main.*=\s*(.*)/\1/g'`" - -for configfile in $configfiles; do \ - [ ! -f $file ] && i=1; \ -done; \ -echo $i</userinput></screen> - </para> - <para> - Another way to test the configuration file is to execute: - </para> - <para> - <screen>$ <userinput>revisor --list-models >/dev/null</userinput></screen> - </para> - <para> - If everything is well, since <literal>STDOUT</literal> is redirected to <filename>/dev/null</filename>, you should see no messages at all. - </para> - - </section> - - <section id="Revisor_Documentation-Testing-Simple_Test_Cases-Configuration_Files"> - <title>Configuration Files</title> - <para> - The main Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. The file lists a series of models, each having their own YUM configuration file in <filename>/etc/revisor/conf.d/</filename>. - </para> - <formalpara> - <title>Testing</title> - <para> - <itemizedlist> - <listitem> - <para> - For each model in <filename>/etc/revisor/revisor.conf</filename>, the <code>main</code> setting for that model should point to a valid file. - </para> - </listitem> - <listitem> - <para> - Each YUM configuration file should work. To verify, run the following command for each configuration file: - </para> - <para> - <screen>$ yum -c <replaceable>$file</replaceable> list kernel</screen> - </para> - </listitem> - </itemizedlist> - </para> - </formalpara> - <formalpara> - <title>Known Errors</title> - <para> - <itemizedlist> - <listitem> - <para> - Revisor has baseurls in YUM repositories set to <ulink url="http://localrepo" />. This URL will not be retrievable for many people, but allows the developers to quickly change mirrors. - </para> - </listitem> - <listitem> - <para> - Repositories that are unavailable at the moment of testing will throw errors Revisor can't do anything about. - </para> - </listitem> - <listitem> - <para> - If the directories <filename>revisor-yumcache/</filename> and <filename>revisor/</filename> in <filename>/var/tmp/</filename>, the default working directory, are not writeable for the user then YUM will throw permission denied errors. - </para> - <para> - Remove <filename>/var/tmp/revisor/</filename> and <filename>/var/tmp/revisor-yumcache/</filename> or run the command with root permissions. - </para> - </listitem> - </itemizedlist> - </para> - </formalpara> - </section> - - <section id="Revisor_Documentation-Testing-Simple_Test_Cases-Compose_Results"> - <title>Requirements for Compose Results</title> - <para> - Although heavily dependent on Anaconda for this part, these are still requirements - </para> - - <formalpara> - <title>ld-linux.so.2</title> - <para> - In the <filename>initrd.img</filename> of the composed product, if 32-bit, <filename>/lib/ld-linux.so.2</filename> (or any other version) should link to <filename>/lib/ld-2.9.so</filename> (or any other version). If <filename>/lib/ld-linux.so.2</filename> links to itself, the media will fail to install. - </para> - </formalpara> - <formalpara> - <title>How to test</title> - <para> - In a terminal, type the following command: - </para> - </formalpara> - <para> - <screen>$ <userinput>lsinitrd /path/to/initrd | grep ld-linux</userinput></screen> - </para> - <para> - See also: <ulink url="https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00115.…" /> - </para> - - </section> - </section> - - <section id="Revisor_Documentation-Testing-Complex_Test_Cases"> - <title>Complex Test Cases</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Testing-Specific_Test_Cases"> - <title>Specific Test Cases</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Tips_and_Tricks.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Tips_and_Tricks.xml deleted file mode 100644 index 488a957..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Tips_and_Tricks.xml +++ /dev/null @@ -1,47 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Tips_and_Tricks"> - <title>Tips and Tricks</title> - <para> - para - </para> - - <section id="Revisor_Documentation-Tips_and_Tricks-The_spin-kickstarts_Package"> - <title>The spin-kickstarts Package</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Tips_and_Tricks-Even_More_Debugging"> - <title>Even More Debugging</title> - <para> - something about using -x to buildinstall scripts - </para> - </section> - - <section id="Revisor_Documentation-Tips_and_Tricks-ksvalidator"> - <title>Kickstart Validator</title> - <para> - something about using -x to buildinstall scripts - </para> - </section> - - <section id="Revisor_Documentation-Tips_and_Tricks-Using_Mirrormanager_For_Mirror_Redirection"> - <title>Using Mirrormanager for Mirror Redirection</title> - <para> - Something about using Mirrormanager to redirect you to the local mirror (so you do not have to edit YUM configuration files). - </para> - </section> - - <section id="Revisor_Documentation-Tips_and_Tricks-The_localrepo_DNS_Alias"> - <title>Using The localrepo DNS Alias</title> - <para> - Something about using the localrepo DNS alias to point to your local mirror (either through real DNS or through /etc/hosts), so you do not have to edit the YUM configuration files. - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Tweaking_The_Build_Process.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Tweaking_The_Build_Process.xml deleted file mode 100644 index d095289..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Tweaking_The_Build_Process.xml +++ /dev/null @@ -1,40 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Tweaking_The_Build_Process"> - <title>Tweaking the build process</title> - <para> - para - </para> - - <section id="Revisor_Documentation-Tweaking_The_Build_Process-Reusing_Existing_Installer_Images"> - <title>Reusing Existing Installer Images</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Tweaking_The_Build_Process-Building_The_Installer_Images_In_Mock"> - <title>Building The Installer Images in Mock</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Tweaking_The_Build_Process-Omitting-isomd5sum"> - <title>Omitting isomd5sums</title> - <para> - para - </para> - </section> - - <section id="Revisor_Documentation-Tweaking_The_Build_Process-Omitting-sha1sums"> - <title>Omitting SHA1SUMS</title> - <para> - para - </para> - </section> - -</chapter> - diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Using_Kickstart.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Using_Kickstart.xml deleted file mode 100644 index 7575bea..0000000 --- a/doc/Reference_Manual/en-US/Revisor_Documentation-Using_Kickstart.xml +++ /dev/null @@ -1,118 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Using_Kickstart"> - <title>Using Kickstart</title> - <para> - Kickstart is a configuration file format for automating installation procedures. Or at least, it was, originally. Nowadays, kickstart files are used as input to the compose tools, including Revisor. - </para> - <para> - Revisor again is unique in that it does not require a kickstart file for input. The other tools only take kickstart configuration files. Revisor though allows most of what is in a kickstart file to be configured interactively in Graphical User Interface mode. - </para> - - <section id="Revisor_Documentation-Using_Kickstart-How_Kickstart_Is_Used"> - <title>How Kickstart Is Used</title> - <para> - There's two cases in which a kickstart file is used differently. One is during the compose of installation media, and the other of course is during the compose of live media, or virtualization media. - </para> - - <section id="Revisor_Documentation-Using_Kickstart-How_Kickstart_Is_Used-Installation_Media"> - <title>Installation Media</title> - <para> - In the case of installation media, the following settings are used: - </para> - <para> - <itemizedlist> - <listitem> - <formalpara> - <title><literal>repo</literal></title> - <para> - The <literal>repo</literal> command in kickstart is used when Revisor is configured to use the repositories configured in the kickstart file only. Use <literal>kickstart_repos = 1</literal> to enable this feature, or set the appropriate checkbox in the Revisor GUI. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title><literal>%packages</literal></title> - <para> - The <literal>%packages</literal> section in kickstart is used to determine the RPM payload on the installation media. It can include groups and packages, and exclude packages. It accepts wildcards, both in includes and excludes of packages (but not groups). - </para> - </formalpara> - </listitem> - </itemizedlist> - </para> - <note> - <title>@core and @base</title> - <para> - By default, groups @core and @base are included in the package manifest. You can specify @base to not be included, by using <literal>%packages --nobase</literal>, but @core cannot be excluded using a kickstart package manifest. - </para> - </note> - <para> - Using <literal>kickstart_exact</literal>, you can exclude @core and @base so that you need to explicitly select them in the kickstart package manifest. - </para> - <para> - Using <literal>kickstart_exact_nevra</literal> ... - </para> - </section> - </section> - - <section id="Revisor_Documentation-Using_Kickstart-The_Kickstart_Package_Manifest"> - <title>The Kickstart Package Manifest</title> - <para> - para - </para> - - <formalpara> - <title>Group @core</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Group @base</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Including groups of packages</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Including a single package</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Excluding a single package</title> - <para> - para - </para> - </formalpara> - - <formalpara> - <title>Using wildcard matches</title> - <para> - para - </para> - </formalpara> - - <section id="Revisor_Documentation-Using_Kickstart-Using_Kickstart_With_Package_NEVRA"> - <title>Using Kickstart with Package NEVRA</title> - <para> - para - </para> - </section> - - </section> - -</chapter> - commit 255cd905e75847bdbe4cd8dcc8fe39b98eb7389d Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org> Date: Thu Jun 18 15:59:24 2009 +0200 Rename to reference manual diff --git a/doc/Reference_Manual/en-US/Appendix.xml b/doc/Reference_Manual/en-US/Appendix.xml new file mode 100644 index 0000000..01258fb --- /dev/null +++ b/doc/Reference_Manual/en-US/Appendix.xml @@ -0,0 +1,475 @@ +<?xml version='1.0'?> +<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<part id="Revisor_Documentation-Appendices"> + <title>Appendices</title> + + <appendix id="Revisor_Documentation-Appendix-Terminology" label="A"> + <title>Terminology</title> + <formalpara id="Revisor_Documentation-Appendix-Terminology-model"> + <title>Model</title> + <indexterm> + <primary>model</primary> + </indexterm> + <para> + A model in Revisor describes a product. + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Appendix-Terminology-package_manifest"> + <title>Package Manifest</title> + <indexterm> + <primary>Package Manifest</primary> + </indexterm> + <para> + A package manifest is the list of groups and packages to include or exclude from a transaction, in a kickstart configuration file. + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Appendix-Terminology-Remix"> + <title>Remix</title> + <indexterm> + <primary>Remix</primary> + </indexterm> + <para> + A Fedora Remix is a product based on Fedora, with Fedora packages and optionally, other packages as well, such as those from third-party repositories. + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Appendix-Terminology-Re-Spin"> + <title>Re-Spin</title> + <indexterm> + <primary>Re-Spin</primary> + <secondary>Fedora Unity Re-Spin</secondary> + </indexterm> + <para> + A Fedora Re-Spin is a product that is composed for the single purpose of including updated software packages into the product. It uses the same compose procedure as the media that the Fedora Project composes and releases, but includes updates. + </para> + </formalpara> + <para> + Fedora Unity releases Fedora Re-Spins every so often, twice or trice per release. + </para> + + <formalpara id="Revisor_Documentation-Appendix-Terminology-Spin"> + <title>Spin</title> + <indexterm> + <primary>Spin</primary> + </indexterm> + <para> + A Fedora Spin is a custom set of software packages, often for a specific audience. Spins include a KDE Spin, which contains KDE software packages rather then the Desktop spin, which is based around GNOME. Similarly, there are XFCE, LXDE, Sugar, Education, Games and Developer Spins. + </para> + </formalpara> + <para> + Fedora Spins have gone through the Spins Process (<ulink url="http://fedoraproject.org/wiki/Spins_Process" />), and have been approved trademark usage by the Fedora Project Board. + </para> + + <formalpara id="Revisor_Documentation-Appendix-Terminology-Package_Sack"> + <title>Package Sack</title> + <indexterm> + <primary>Package Sack</primary> + </indexterm> + <para> + When YUM creates a list of packages available from the repositories configured, including package metadata such as dependencies and provided capabilities for each package, YUM creates a PackageSack. It's basically a large bag with all Package Objects, filtered by compatible architectures for the configured architecture. + </para> + </formalpara> + </appendix> + + <appendix id="Revisor_Documentation-Appendix-Configuration_Reference" label="B"> + <title>Configuration Reference</title> + <para> + This is the configuration reference for Revisor. Options are listed in alphabetical order. + </para> + + <section id="Revisor_Documentation-Appendix-Configuration_Reference-Media_Options"> + <title>Configuration Options</title> + <para> + <table> + <title>Configuration Options</title> + <tgroup cols="4" title="Configuration Options"> + <colspec colname="column1" colwidth="1*" /> + <colspec colname="column25" colwidth="4*" /> + <colspec colname="column67" colwidth="2*" /> + <colspec colname="column89" colwidth="2*" /> + <thead> + <row> + <entry namest="column1" nameend="column89" align="center">Configuration Options</entry> + </row> + <row> + <entry namest="column1" nameend="column25">Configuration Directive</entry> + <entry namest="column67" nameend="column89">CLI Option</entry> + </row> + <row> + <entry namest="column1"> </entry> + <entry namest="column25">Possible Values</entry> + <entry>Default</entry> + <entry>Context</entry> + </row> + <row> + <entry namest="column1"> </entry> + <entry namest="column25" nameend="column67">Description</entry> + <entry namest="column89"> </entry> + </row> + </thead> + <tbody> + <row> + <entry namest="column1" nameend="column25"><literal>answer_yes</literal></entry> + <entry namest="column67" nameend="column89"><literal>-y</literal>, <literal>--yes</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Answer <emphasis>yes</emphasis> to all questions.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>clean_up</literal></entry> + <entry namest="column67" nameend="column89"><literal>--clean-up</literal></entry> + </row> + <row> + <entry namest="column25">0, 1, 2</entry> + <entry>1</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Should Revisor not clean up at all (0), clean up it's temporary build data (1), or everything -this includes the yum cache (2).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>copy_dir</literal></entry> + <entry namest="column67" nameend="column89"><literal>--copy-dir</literal></entry> + </row> + <row> + <entry namest="column25"><code>[dir]</code></entry> + <entry>False</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">A directory tree to copy onto the media created. In the case of installation media, the contents of the directory specified are copied onto <code>cdrom:/files/</code>. In the case of live media, the contents of the directory specified are copied onto the root filesystem of the live system.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>copy_local</literal></entry> + <entry namest="column67" nameend="column89"><literal>--copy-local</literal></entry> + </row> + <row> + <entry namest="column25"> </entry> + <entry>False</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Tell Revisor to copy files, even when they are local. This applies to relative corner-cases where the repositories or the <code>destination_directory</code> is mounted over NFS, and some actions cannot be performed.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>debuglevel</literal></entry> + <entry namest="column67" nameend="column89"><literal>-d</literal>, <literal>--debug</literal></entry> + </row> + <row> + <entry namest="column25">0 - 9</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">The level of debugging. 0 is the lowest debug level, whereas 9 is the highest. Revisor turns up the volume quickly. The logfile on debug level 9 may very easily become 20-30MB.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>destination_directory</literal></entry> + <entry namest="column67" nameend="column89"><literal>--destination-directory</literal></entry> + </row> + <row> + <entry namest="column25"><code>/srv/revisor/</code></entry> + <entry><code>[path]</code></entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">The destination directory for the product. Revisor creates a sub-directory with the name of the model used, and places the product in that directory.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>getsource</literal></entry> + <entry namest="column67" nameend="column89"><literal>--source</literal></entry> + </row> + <row> + <entry namest="column25"> </entry> + <entry>False</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to obtain the source along with the binary RPMs used. This is False by default, and therefor the source is not included by default. Note that if you are distributing your product to third parties, you need to be able to provide the sources along with the binary product.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>include_bootiso</literal></entry> + <entry namest="column67" nameend="column89"><literal> </literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to include the relatively large boot.iso on the optical installation media created. Setting this to 0 will still include boot.iso in the installation tree created (if configured with <code>media_installation_tree</code><footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Documentation-Compose_Process_Details" /> for more details.</para></footnote>)</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>kickstart_default</literal></entry> + <entry namest="column67" nameend="column89"><literal>--kickstart-default</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to set the isolinux.cfg entry that makes the installer use the kickstart included on the media, as a default.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>kickstart_exact</literal></entry> + <entry namest="column67" nameend="column89"><literal>--kickstart-exact</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Tells Revisor to ignore @core and @base groups (like with <code>%packages --nobase</code>) and only add what is in the package manifest.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>kickstart_exact_nevra</literal></entry> + <entry namest="column67" nameend="column89"><literal>--kickstart-exact-nevra</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Tells Revisor to only add what is in the package manifest. In addition, if the transaction changes (because of dependency resolving, for example), Revisor will stop composing.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>kickstart_file</literal></entry> + <entry namest="column67" nameend="column89"><literal>--kickstart</literal></entry> + </row> + <row> + <entry namest="column25"><code>[file]</code></entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">What kickstart file to use. When in CLI mode, this is a mandatory setting.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>kickstart_include</literal></entry> + <entry namest="column67" nameend="column89"><literal>--kickstart-include</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to include the kickstart on the media so that the installer may find it as <filename>cdrom:/ks.cfg</filename>.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>kickstart_save</literal></entry> + <entry namest="column67" nameend="column89"><literal>--kickstart-save</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Where to save the resulting kickstart. In GUI mode, when changes to the package set can be applied, saves those changes out into a new kickstart file.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_bluray_duallayer</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-bluray-dl</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create Bluray Duallayer installation media (47GiB).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_bluray</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-bluray</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create Bluray installation media (23GiB).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_bluray_duallayer</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-bluray-dl</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create Bluray Duallayer installation media (47GiB).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_cd</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-cd</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create CD installation media (685MiB).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_dvd</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-dvd</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create DVD installation media (4.3GiB).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_dvd_duallayer</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-dvd-dl</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create DVD Duallayer installation media (8.0GiB).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_tree</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-tree</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create a an installation tree<footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Documentation-Compose_Process_Details" /> for more details.</para></footnote> (for publication over HTTP or FTP, or through Cobbler). No size limit.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_installation_unified</literal></entry> + <entry namest="column67" nameend="column89"><literal>--install-unified</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create a unified ISO, installation media (no size limit).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>media_live_optical</literal></entry> + <entry namest="column67" nameend="column89"><literal>--live-optical</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether to create Optical Live media (size unknown).</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>model</literal></entry> + <entry namest="column67" nameend="column89"><literal>--model</literal></entry> + </row> + <row> + <entry namest="column25"> </entry> + <entry><code>[model]</code></entry> + <entry>global</entry> + </row> + <row> + <entry namest="column25" nameend="column89">The model to use.</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>report_sizes</literal></entry> + <entry namest="column67" nameend="column89"><literal>--report_sizes</literal></entry> + </row> + <row> + <entry namest="column25">0, 1</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Report the sizes of RPM packages used. Lists the biggest packages in the transaction</entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>mode_respin</literal></entry> + <entry namest="column67" nameend="column89"><literal>--respin</literal></entry> + </row> + <row> + <entry namest="column25"> </entry> + <entry>False</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">Whether Revisor should operate in <emphasis>respin</emphasis> mode. See also <xref linkend="Revisor_Documentation-Compose_Process_Details-Respin_Mode" /></entry> + </row> + + <row> + <entry namest="column1" nameend="column25"><literal>working_directory</literal></entry> + <entry namest="column67" nameend="column89"><literal>-d</literal>, <literal>--debug</literal></entry> + </row> + <row> + <entry namest="column25">0 - 9</entry> + <entry>0</entry> + <entry>global, model</entry> + </row> + <row> + <entry namest="column25" nameend="column89">The level of debugging. 0 is the lowest debug level, whereas 9 is the highest. Revisor turns up the volume quickly. The logfile on debug level 9 may very easily become 20-30MB.</entry> + </row> + + </tbody> + </tgroup> + </table> + </para> + + </section> + + </appendix> + +</part> diff --git a/doc/Reference_Manual/en-US/Author_Group.xml b/doc/Reference_Manual/en-US/Author_Group.xml new file mode 100644 index 0000000..37b4bf5 --- /dev/null +++ b/doc/Reference_Manual/en-US/Author_Group.xml @@ -0,0 +1,16 @@ +<?xml version='1.0'?> +<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<authorgroup> + <author> + <firstname>Jeroen</firstname> + <surname>van Meeuwen</surname> + <lineage>RHCE</lineage> + <affiliation> + <orgname>Fedora Project</orgname> + <orgdiv>Contributor</orgdiv> + </affiliation> + <email>kanarip(a)fedoraproject.org</email> + </author> +</authorgroup> diff --git a/doc/Reference_Manual/en-US/Book_Info.xml b/doc/Reference_Manual/en-US/Book_Info.xml new file mode 100644 index 0000000..0b84805 --- /dev/null +++ b/doc/Reference_Manual/en-US/Book_Info.xml @@ -0,0 +1,37 @@ +<?xml version='1.0'?> +<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<bookinfo id="Revisor_Documentation-Documentation"> + <title>Reference Manual</title> + <subtitle>Revisor Complete Installation, Configuration and Tweaking Reference</subtitle> + <productname>Revisor</productname> + <productnumber>2.1.5</productnumber> + + + <abstract> + <para> + This is Revisors upstream documentation. + </para> + </abstract> + <corpauthor> + <inlinemediaobject> + <imageobject> + <imagedata format='SVG' fileref="Common_Content/images/title_logo.svg" /> + </imageobject> + <textobject><phrase>Logo</phrase></textobject> + </inlinemediaobject> + </corpauthor> + <copyright> + <year>&YEAR;</year> + <holder>&HOLDER;</holder> + </copyright> + <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> +</bookinfo> + + + diff --git a/doc/Reference_Manual/en-US/Preface.xml b/doc/Reference_Manual/en-US/Preface.xml new file mode 100644 index 0000000..02af0ea --- /dev/null +++ b/doc/Reference_Manual/en-US/Preface.xml @@ -0,0 +1,56 @@ +<?xml version='1.0'?> +<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<preface id="Revisor_Documentation-Preface"> + <title>Preface</title> + <para> + This is the documentation for Revisor, a utility to create and customize your own Linux distribution based on Fedora, Red Hat Enterprise Linux or CentOS. + </para> + + <section id="Revisor_Documentation-Preface-About_The_Contributors"> + <title>About the Contributors</title> + <formalpara> + <title>Author</title> + <para> + <emphasis>Jeroen van Meeuwen</emphasis> (RHCE, LPIC-2, MCP, CCNA) is currently a Senior System Engineer, specialized in Linux systems and Systems Architecture, working for Operator Groep Delft in The Netherlands. His experience with computers goes back to the early '90s, with a Philips P2000T being over a decade old, little tapes containing programs but most importantly games, and 16K memory cartridges. Since 1998, he has been involved with Red Hat Linux (5.2 at that time), and was an early adopter of Fedora Core Linux in November 2003, until his first real contributions to Free and Open Source Software were made in 2005. + </para> + </formalpara> + <para> + As a contributor to Free and Open Source Software within the Fedora community, amongst other programs, Jeroen has developed Revisor, a Python framework to build distributions with. With regards to Configuration Management, Jeroen currently maintains or co-maintains -amongst other packages- the entire stack of packages related to Puppet + </para> + + <formalpara> + <title>Contributors</title> + <para> + <emphasis>Jonathan Steffan</emphasis> is a community volunteer based in Colorado, USA, and has a long standing record within Fedora for packaging Zope (Web Application Server), Plone (Open Source Content Management System), providing compat-python2.4 packages for Fedora 7 and 8, and voluntarily administering the Fedora Unity servers, Zope and Plone instances, creating and further developing Revisor and pyJigdo. + </para> + </formalpara> + </section> + + <section id="Revisor_Documentation-Preface-About_Fedora_Unity"> + <title>About Fedora Unity</title> + <para> + The Fedora Unity Project consists of a group of concerned peers from within the Fedora community that strive to bring the best possible solutions to the community, in a consistent manner. This, amongst other things, resulted in extensive documentation on various topics often referred to on the Web, published under the Open Documentation License v1.0. + </para> + <para> + The Fedora Unity Project is a different project then the official Fedora Project. The people behind the Fedora Unity Project often contribute to the Fedora Project directly as well, but there's little to no bureaucracy in the Fedora Unity Project. Why do you think these Re-Spins are not released by the Fedora Project itself? + </para> + </section> + + <section id="Revisor_Documentation-Preface-About_This_Document"> + <title>About this Document</title> + <para> + This document is licensed under the Open Publication License version 1.0, which is available at <ulink url="http://www.opencontent.org/openpub/" />. You can get the latest version from <ulink url="http://kanarip.fedorapeople.org/Revisor_Documentation/en-US/pdf/Revisor_Doc…" /> (PDF), and it's sources live at <ulink url="http://git.fedorahosted.org/git/?p=revisor;a=tree;f=doc" />. + </para> + </section> + + <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"> + <xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude"> + <xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + </xi:fallback> + </xi:include> + +</preface> diff --git a/doc/Reference_Manual/en-US/Reference_Manual.ent b/doc/Reference_Manual/en-US/Reference_Manual.ent new file mode 100644 index 0000000..9edfaea --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual.ent @@ -0,0 +1,5 @@ +<!ENTITY PRODUCT "Revisor"> +<!ENTITY BOOKID "Reference Manual"> +<!ENTITY YEAR "2007 - 2009"> +<!ENTITY HOLDER "Jeroen van Meeuwen"> + diff --git a/doc/Reference_Manual/en-US/Reference_Manual.xml b/doc/Reference_Manual/en-US/Reference_Manual.xml new file mode 100644 index 0000000..757504d --- /dev/null +++ b/doc/Reference_Manual/en-US/Reference_Manual.xml @@ -0,0 +1,27 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<book> + <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="Revisor_Documentation-Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Features.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Installation.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Configuration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Using_Kickstart.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Compose_Process_Details.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Plugins.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Tweaking_The_Build_Process.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Tips_and_Tricks.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Frequently_Asked_Questions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Testing.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Revisor_Documentation-Development.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + + <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <index /> + <xi:include href="Appendix.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + +</book> + diff --git a/doc/Reference_Manual/en-US/Revision_History.xml b/doc/Reference_Manual/en-US/Revision_History.xml new file mode 100644 index 0000000..68432a0 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revision_History.xml @@ -0,0 +1,26 @@ +<?xml version='1.0'?> +<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<appendix id="appe-Publican-Revision_History"> + <title>Revision History</title> + <simpara> + <revhistory> + <revision> + <revnumber>1.0</revnumber> + <date></date> + <author> + <firstname></firstname> + <surname></surname> + <email></email> + </author> + <revdescription> + <simplelist> + <member></member> + </simplelist> + </revdescription> + </revision> + </revhistory> + </simpara> +</appendix> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Compose_Process_Details.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Compose_Process_Details.xml new file mode 100644 index 0000000..64515ff --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Compose_Process_Details.xml @@ -0,0 +1,431 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Compose_Process_Details"> + <title>Compose Process Details</title> + <para> + This chapter lists the details of the compose process as well as dives deep into the features of Revisor. + </para> + + <section id="Revisor_Documentation-Compose_Process_Details-Overview"> + <title>Overview</title> + <titleabbrev id="Compose_Process_Details-Overview">Overview</titleabbrev> + <para> + Of course, the compose process for installation media is a little different then the compose process for live media. + </para> + <para> + When composing, Revisor starts out doing the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Revisor initiates and loads plugins, options, and defaults. At this point, Revisor has a so-called <emphasis>ConfigStore</emphasis> that holds all options Revisor knows about. + </para> + </listitem> + <listitem> + <para> + Revisor reads the options from the command-line. + </para> + </listitem> + <listitem> + <para> + Revisor reads the configuration file specified with the <code>--config</code> command-line parameter, or uses it's builtin default, <filename>/etc/revisor/revisor.conf</filename>. + </para> + </listitem> + <listitem> + <para> + Revisor reads the global <code>[revisor]</code> section for all settings available in it's <emphasis>ConfigStore</emphasis> and sets those configured in the global section. Remember that if an option is not available in the <emphasis>ConfigStore</emphasis> but is configured in the global configuration section, it is ignored. + </para> + </listitem> + <listitem> + <para> + If a model is specified in the configuration file's global section <code>[revisor]</code>, Revisor will set that model to be used and loads it. + </para> + </listitem> + <listitem> + <para> + If a model has been specified on the command-line, with option <code>--model</code>, Revisor loads that model. + </para> + </listitem> + <listitem> + <para> + When loading the model, Revisor again iterates over all the settings that are in the <emphasis>ConfigStore</emphasis>, checks if the setting has been configured in the model section, and adjusts the setting in the <emphasis>ConfigStore</emphasis> if necessary. Again remember that if the <emphasis>ConfigStore</emphasis> does not know about one or the other option already, that setting is ignored. + </para> + </listitem> + <listitem> + <para> + Now that the defaults and configuration file settings have been applied to the <emphasis>ConfigStore</emphasis>, it is time for Revisor to look at the options specified on the command-line to see if you wanted to override anything. + </para> + </listitem> + <listitem> + <para> + While loading each configuration setting available in the global <code>[revisor]</code>, model-specific sections and/or command-line, Revisor checks every settings against a function that is specifically written to check such setting. For example, the label of an ISO cannot be longer then 32 characters. + </para> + </listitem> + <listitem> + <para> + Especially in CLI mode, these settings build up the task list for Revisor. If there's nothing to do, Revisor will throw an error explaining what's missing. If there's things to do that cannot be done in one run, Revisor will throw an error explaining that. + </para> + </listitem> + <listitem> + <para> + In Graphical User Interface mode however, if the settings loaded so far are all OK, the GUI will start. Since you can still adjust a few settings from within the GUI, the settings loaded so far will be the defaults for configuration settings that have a dialog for you to adjust them with, throughout the rest of the process. + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Installation_Media"> + <title>Installation Media</title> + <para> + As we've explained before, composing installation media is a little different then composing live media. That's not just because installation media should start an installation procedure and live media should show you a nice, shiny, fully-functional Desktop. + </para> + <para> + For one, installation media allows split media. This means that Revisor can span the payload of the product over multiple ISO images or multiple discs, if you will. When composing installation media, Revisor basically does the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Of course, Revisor goes through the loading of configuration options mentioned in the <xref linkend="Revisor_Documentation-Compose_Process_Details-Overview" endterm="Compose_Process_Details-Overview" />. + </para> + </listitem> + <listitem> + <para> + When you're done specifying options in the GUI, or when Revisor thinks it can go ahead using the options specified in CLI mode, it takes the list of packages selected from either the GUI or the kickstart <code>%packages</code> manifest. + </para> + <para> + Not getting too deep into details here, yet, because some of these things are routines shared with other composing modes, but here's a few additional considerations Revisor makes when doing the package selection. + </para> + <para> + <itemizedlist> + <listitem> + <para> + Normally, a kickstart <code>%packages</code> manifest only allows you to select package <emphasis>names</emphasis>. With Revisor though, you can select exact package <emphasis>NEVRA</emphasis> to select a certain version or architecture for the package that you want. Additionally, if a package is not available, Revisor searches the <emphasis>Provides</emphasis> of the available packages. + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Live_Media"> + <title>Live Media</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Respin_Mode"> + <title>Respin Mode</title> + <para> + Revisor has a respin mode that in some aspects differs from the regular routines. It is intended to reflect behaviour of tools in use by the Fedora Project Release Engineering team as closely as possible. + </para> + <para> + Re-Spin mode only affects installation media products. + </para> + <para> + In Re-Spin mode, the way the RPM payload is determined from kickstart differs from Revisor's normal procedures. See <xref linkend="Revisor_Documentation-Using_Kickstart" /> for more details on using a kickstart package manifest. + </para> + <para> + A kickstart file's so-called <xref linkend="Revisor_Documentation-Appendix-Terminology-package_manifest" /> usually looks like: + </para> + <para> + <screen>%packages +@group1 +@group2 --nodefaults +@group3 --optional +package1 +package2 +-package3 +%end</screen> + </para> + <para> + Which tells us the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Include all mandatory and default packages from group1 + </para> + </listitem> + <listitem> + <para> + Include all mandatory packages from group2 + </para> + </listitem> + <listitem> + <para> + Include all mandatory, default and optional packages from group3 + </para> + </listitem> + <listitem> + <para> + Include package1, and package2 + </para> + </listitem> + <listitem> + <para> + Exclude package3 + </para> + </listitem> + </itemizedlist> + </para> + <para> + Depending on how you use this instructions or information, there is a slight difference in the package set that ends up on the media you compose. + </para> + + <section id="Revisor_Documentation-Compose_Process_Details-Respin_Mode-Selecting_Groups"> + <title>Selecting Groups</title> + <para> + Selecting groups has the following logic: When you load a repository you may also load the groups file (often referred to as 'comps' or 'comps.xml'). This comps file is an XML file with categories, groups (per category), and per group: + </para> + <para> + <itemizedlist> + <listitem> + <para> + a list of mandatory packages. If you select or include the group, these packages come with it. + </para> + </listitem> + <listitem> + <para> + a list of default packages. If you select or include the group, these packages will come with it as a default. If you only want the mandatory, minimum set of packages for this group, in a kickstart package manifest append <code>--nodefaults</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Deselect all packages</emphasis>. + </para> + </listitem> + <listitem> + <para> + a list of optional packages. If you select a group you have not yet selected these packages. To select the optional packages of a group, in a kickstart package manifest append <code>--optional</code> to the group line or in the Revisor GUI, right-click on the group and choose <emphasis>Select all optional packages</emphasis>. + </para> + </listitem> + <listitem> + <para> + a list of conditionals. If you select this group, these conditionals are thrown into the package sack and transaction information and include or exclude other packages. Suppose you select the '@nl-support' or “Dutch Support” group from the Languages or Localization category, you would end up with support for the Dutch language in all applications that have that kind of support. + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Respin_Mode-Select_Matching_Packages"> + <title>Select Matching Packages</title> + <para> + This is the logic Revisor applies when running in Re-Spin mode (on the CLI, specify <code>--respin</code>). It imitates the behavior pungi has, and thus enables you to copy that behavior. Note that <code>--respin</code> has other implications as well. + </para> + <para> + First of all, it iterates the groups in the kickstart package manifest. For each group, it appends the names of the mandatory packages to a list, and depending on the additional parameters specified with that group (<code>--nodefaults</code> or <code>--optional</code>), appends the names of the other packages in that group as well. + </para> + <para> + Then it iterates over the package names in the package manifest. These package names are appended to the same list of package names too. This includes package 'names' with some sort of wildcard (?, or *). + </para> + <para> + Then it iterates over all the excluded packages, appending each of those to the YUM configuration exclude list. + </para> + <para> + Now that Revisor has a very simple, flat list of package names, it uses YUM's internal matching logic 5 to get what packages in the repositories matched exactly (by name), matched (by wildcard) and did not match at all. Revisor then selects the exact matches and matches, adding them to the transaction. + </para> + </section> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving"> + <title>Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + </indexterm> + <para> + Dependency resolving is the area where some of the efficiency Revisor can gain for you comes from. While of course there is specific reasons to do things one way, or the other, most people I speak to about Revisor, it is not very clear why, or what Revisor does in this area. First of all, there's two ways of resolving dependencies: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Inclusive Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + <secondary>Inclusive</secondary> + </indexterm> + <para> + Iterate all packages in the transaction and list their requirements, then for each of those requirements, find all packages that provide a matching capability, add those packages to the transaction, and don't forget to add the requirements those packages have themselves, back into the pile of (unmet) requirements. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Exclusive Dependency Resolving</title> + <indexterm> + <primary>Dependency Resolving</primary> + <secondary>Inclusive</secondary> + </indexterm> + <para> + Iterate all the packages and for each of the requirements found, find the best package that meets the requirement. This is also YUMs default behavior. Anaconda uses YUM during the installation, and this is the behaviour of YUM used during the installation. + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + + <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Inclusive"> + <title>Inclusive Dependency Resolving</title> + <para> + Hypothetically, you could describe inclusive dependency as follows: + </para> + <para> + <screen>final_packages = [] +more_to_do = True +while more_to_do: +more_to_do = False +for package in packages: + if package in final_packages: + continue + + dependencies = find_package_dependencies() + for dependency in dependencies: + pulled_in_package = pull_in_dependency() + if pulled_in_package not in final_packages: + packages.append(pulled_in_package) + more_to_do = True</screen> + </para> + <para> + So, what does this mean? Basically, it means that if there is a requirement for a capability, all packages providing that capability are being pulled in. Now imagine package 'foo' requires capability 'web-client'. There's a number of packages providing that capability, right? So you get Firefox, lynx, elinks, konqueror, safari, Netscape, Internet Explorer, emacs, for free! All of those pull in their own dependencies also, of course. + </para> + <note> + <para> + If you catch this before it catches you, you can prevent the packages from being pulled in during dependency resolving by not making the package available in the <xref linkend="Revisor_Documentation-Appendix-Terminology-Package_Sack" /> in the first place, using the <literal>-firefox</literal> syntax in the kickstart package manifest, and setting <literal>kickstart_uses_pkgsack_excludes</literal> to 1. + </para> + </note> + <note> + <para> + You may have thought of it; pulling in packages this way may give you a package set (or <emphasis>RPM payload</emphasis>) that has conflicting packages. Imagine package <application>foo</application> requiring capability <application>bar</application>, which is provided by two packages that conflict with one another (either on explicit <literal>Conflicts:</literal> RPM header or file level). Both will be pulled in, hence disabling you to install everything (<literal>'*'</literal> or -previously- <literal>@Everything</literal> in the kickstart package manifest). + </para> + </note> + + <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Makes_Sense"> + <title>When This Makes Sense</title> + <para> + If you are composing a large distribution of which 3 million users in even so many different situations having so many different expectations and desires, you will want this behaviour, since you won't be able to determine which one of the packages for each capability someone in that group wants, and which one may not want. Or, in case of upgrades, what the system needs. Shipping them all on the same media is the best solution in these cases. + </para> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Inclusive-When_This_Does_Not_Make_Sense"> + <title>When This Does Not Make Sense</title> + <para> + <itemizedlist> + <listitem> + <para> + When creating installation media to be installed unattended, or to be used in conjunction with deployment strategies + </para> + </listitem> + <listitem> + <para> + When creating installation media to be upgrading PCs you have controlled from the beginning, such as in a company + </para> + </listitem> + <listitem> + <para> + Installation for a small group of users or systems + </para> + </listitem> + <listitem> + <para> + When creating minimal installation media, or media with a minimal RPM payload. + </para> + </listitem> + <listitem> + <para> + When creating installation media that is to be used with installing "Everything" in the RPM payload. + </para> + </listitem> + </itemizedlist> + </para> + </section> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Dependency_Resolving-Exclusive"> + <title>Exclusive Dependency Resolving</title> + <para> + Exclusive dependency resolving is what YUM does when you execute a <application>yum install</application>. Unless you've specified one of the packages satisfying any of the dependencies in the transaction, YUM is going to look up the best match for you. This results in the installation of only one package providing the requirement(s) of other packages, rather then all packages providing said requirement being installed. + </para> + <para> + As an example, imagine you install a package foo which requires capability web-client. Using exclusive dependency resolving, YUM would select one package providing the web-client capability whereas inclusive dependency resolving would include all packages providing the web-client capability. + </para> + <para> + During the installation procedure, one of the major features of installation media, anaconda is going to use YUM dependency resolving to satisfy all the dependencies. + </para> + <note> + <title>Installation Procedure !== Upgrade Procedure</title> + <para> + Note that an installation procedure is not the same as an upgrade procedure. With an installation procedure for example, you have control over the partitioning layout whereas with an upgrade procedure, you have none. More importantly, during an upgrade procedure, the (already installed) system has an existing package set which needs to be updated/upgraded and thus could possibly introduce dependency resolving problems, because of third party packages installed on the system, or because the media used to upgrade the system with does not contain the software packages needed to complete the upgrade RPM transaction. + </para> + </note> + </section> + + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Copying_Arbitrary_Files_Onto_The_Media"> + <title>Copying Arbitrary Files Onto the Media</title> + <para> + With <literal>--copy-dir</literal>, you can specify a path Revisor should copy onto the media. + </para> + <formalpara> + <title>Installation Media</title> + <para> + In the case of installation media, the path specified with <literal>--copy-dir</literal> will be copied recursively to the <filename>files/</filename> sub-directory at the root of the ISO image (or the first ISO image if you compose split media). + </para> + </formalpara> + <para> + A few use-case examples: + </para> + <para> + <itemizedlist> + <listitem> + <para> + If one kickstart profile is not enough for you to deploy the product onto your systems, create a directory that holds multiple kickstart files and specify the path to that directory using <literal>--copy-dir</literal>. The kickstart files now end up available to the installation procedures as <filename>cdrom:/files/*.ks</filename>, and can thus be used by specifying them on the kernel cmdline (<code>ks=cdrom:/files/profile1.ks</code>), or, when used in combination with <literal>--isolinux-cfg</literal> from the <xref linkend="Revisor_Documentation-Plugins-Upstream-Isolinux_Plugin" endterm="Isolinux_Plugin" />, can be added as an option in the isolinux menu. + </para> + </listitem> + <listitem> + <para> + If you have files or scripts that need to be copied onto, or run on, the installed system before it attempts to reboot and operate normally, you can use <literal>--copy-dir</literal> to make these files and scripts available during the installation and copy or execute them from either <code>%pre</code> or <code>%post</code> scripts. + </para> + </listitem> + </itemizedlist> + </para> + <formalpara> + <title>Live Media</title> + <para> + In the case of live media, the path specified with <literal>--copy-dir</literal> will be copied recursively onto the root directory (<filename>/</filename>) of the live media filesystem (which is probably loop-mounted onto <filename>/var/tmp/revisor/</filename>). + </para> + </formalpara> + <para> + If, for example, you want to copy a home directory onto the live media, and the home directory you want to copy is at <filename>/home/user1/</filename> on the composing system, you copy this directory so that the root of that new directory has a sub-directory <filename>home/</filename> which in turn contains a sub-directory <filename>user1/</filename>: + </para> + <para> + <screen>$ <userinput>mkdir -p /tmp/something/home/</userinput> +$ <userinput>cp -a /home/user1 /tmp/something/home/.</userinput> +$ <userinput>revisor [options] --copy-dir /tmp/something/</userinput></screen> + </para> + </section> + + <section id="Revisor_Documentation-Compose_Process_Details-Cleaning_Up"> + <title>Cleaning Up</title> + <para> + Revisor tends to clean up after itself by default. If a product compose succeeds, you (probably) don't need to change this default behaviour. However, by default, Revisor tends to leave the YUM cache directories untouched. This is to prevent you from having to download all the packages a second, third or more times when you run another compose. + </para> + <para> + To change this default behaviour, Revisor has an option <literal>--clean-up</literal>. The default value for this option is <literal>1</literal>, meaning Revisor will clean up it's temporary, compose-specific files, but no files that could be re-used. Specifying <literal>--clean-up=0</literal> will cause Revisor to leave everything behind and not clean anything up at all. This is most ideal for troubleshooting purposes, where one needs to examine the temporary, compose-specific files and see what went wrong. To clean up everything however, because for example you might be low on disk-space, use <literal>--clean-up=2</literal>. Revisor will then also clean up the files that could be re-used. + </para> + + <section id="Revisor_Documentation-Compose_Process_Details-Cleaning_Up-Exception-to-the-Rule"> + <title>Exception to the Rule</title> + <para> + There's one exception to the rule of cleaning up. <filename>/var/tmp/revisor/</filename>, or put more accurately, the path specified as the <code>installroot</code> in the YUM configuration file configured with the model used to compose the product, will not be cleaned up afterwards. When composing live media, this directory may still be in use as a mount-point for the live media filesystem. Removing this directory recursively in these cases would not make sense. + </para> + </section> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Configuration.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Configuration.xml new file mode 100644 index 0000000..9d435bf --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Configuration.xml @@ -0,0 +1,280 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Configuration"> + <title>Configuration</title> + <para> + Revisor configuration can be performed using <xref linkend="Revisor_Documentation-Configuration-Files" />, or through <xref linkend="Revisor_Documentation-Configuration-Command-line_Options" />. + </para> + + <section id="Revisor_Documentation-Configuration-Files"> + <title>Configuration Files</title> + <para> + Revisor uses configuration files for a large part of it's operations. These files mostly reside in <filename>/etc/revisor/</filename>. There is two types of files Revisor uses: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Revisor Configuration Files</title> + <para> + Revisor configuration files, such as <filename>/etc/revisor/revisor.conf</filename>, contain information and settings unique to Revisor. A Revisor configuration file is where you specify default options, and include information on different products you want to compose. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>YUM Configuration Files</title> + <para> + YUM configuration files, such as the files in <filename>/etc/revisor/conf.d/</filename>, contain configuration for YUM. To be more precise, Revisor doesn't even handle the files (it let's YUM do so). The files in <filename>/etc/revisor/conf.d/</filename> practically contain the same information as <filename>/etc/yum.conf</filename> combined with the files in <filename>/etc/yum.repos.d/</filename> (but not exactly the same content!). + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + + <section id="Revisor_Documentation-Configuration-Files-_etc_revisor_revisor.conf"> + <title><filename>/etc/revisor/revisor.conf</filename></title> + <para> + The default Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. This configuration file contains two sections: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title><literal>[revisor]</literal></title> + <para> + The global section. Options specified in this section apply to all the models defined in this configuration file. + </para> + </formalpara> + <para> + See also: <xref linkend="Revisor_Documentation-Configuration-Global_and_Model_Configuration" /> + </para> + </listitem> + <listitem> + <formalpara> + <title><literal>[<replaceable>model</replaceable>]</literal></title> + <para> + Model configuration. One section per <xref linkend="Revisor_Documentation-Appendix-Terminology-model" />. + </para> + </formalpara> + <para> + See also: <xref linkend="Revisor_Documentation-Configuration-Global_and_Model_Configuration" /> + </para> + </listitem> + </orderedlist> + </para> + <para> + Model sections basically define a single product. Amongst other things, the distribution name, release version, architecture for the product to be composed and what YUM configuration file to use, are (often) defined on a per-model basis. There is a large number of settings available for models, and they are all related to how the product is going to look like. The product name, the location of the RPM payload for installation media, the ISO label, the YUM configuration file to use, are all model settings. + </para> + <para> + Using models, you can reproduce the outcome of the compose process, a <emphasis>product</emphasis>, simply by not changing the model configuration anymore. If you want something different, you can just add another model section, and name it differently. + </para> + <para> + To see what models are available with the Revisor standard package, use: + </para> + <para> + <screen>$ <userinput>revisor --list-models</userinput></screen> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Files-_etc_revisor_conf.d_"> + <title><filename>/etc/revisor/conf.d/</filename></title> + <para> + The default YUM configuration files used by Revisor. In a model configuration section, the <literal>main =</literal> setting points to one of the YUM configuration files in <filename>/etc/revisor/conf.d/</filename> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Files-Updates"> + <title>Updates to Configuration Files</title> + <para> + The Revisor packages are not allowed to overwrite files in <filename>/etc/</filename>, and they should thus not do so. If an update to Revisor is installed on your system, files with the extension <literal>.rpmnew</literal> may be created --if you had changed anything in the file before applying the update. Since this world isn't perfect, configuration errors may exist in the configuration files shipped with Revisor. Please pay close attention to updates to these configuration files by examining the <literal>.rpmnew</literal> files. + </para> + <para> + You can use any file location (not just <filename>/etc/revisor/</filename>) for your own custom configuration. + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Files-Changing_Configuration_Files"> + <title>Changing Configuration Files</title> + <para> + If you are creating your own models off of the ones that ship with Revisor itself, please consider using an alternative configuration file (a file other then <filename>/etc/revisor/revisor.conf</filename>, or copy the original file for safekeeping. This way, you can always return to a working, sample configuration file and test whether it is Revisor causing errors, or configuration mistakes. + </para> + </section> + + </section> + + <section id="Revisor_Documentation-Configuration-Global_and_Model_Configuration"> + <title>Global and Model Configuration</title> + <para> + The default Revisor configuration file, <filename>/etc/revisor/revisor.conf</filename> consists of multiple sections (the file is in .INI format). One is the <literal>[revisor]</literal> global section, where you specify configuration options that apply to each other section or <xref linkend="Revisor_Documentation-Appendix-Terminology-model" />. + </para> + <para> + The options specified in the global and model configuration sections apply to the Revisor compose in the following order: + </para> + <para> + <orderedlist> + <listitem> + <para> + The options from the global section are read, tested and set. + </para> + </listitem> + <listitem> + <para> + The options from a model section are read, tested and set, regardless of whether the global section had caused the setting to be set to a certain value already. + </para> + </listitem> + </orderedlist> + </para> + <para> + For example, if you know all the models in a configuration file are optical live media products, the configuration sections could look like the following: + </para> + <para> + <screen>[revisor] +# Optical live media for all models +media_live_optical = 1 + +[model1] +main = /etc/revisor/conf.d/revisor-model1.conf +description = The model1 product +architecture = i386 +# This is already configured in the global section of +# this configuration file and can thus be removed. +#media_live_optical = 1</screen> + </para> + <note> + <title>When Running the GUI</title> + <para> + Note that when running Revisor in Graphical User Interface mode, you can still change a lot of the settings supplied by Revisor through the configuration files loaded. When you are running Revisor in GUI mode, the configuration files supply the defaults. + </para> + </note> + </section> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories"> + <title>YUM Repository Configuration</title> + <para> + The files in <filename>/etc/revisor/conf.d/</filename> are YUM configuration files. Revisor directs YUM to use these files during the compose process, and does not handle these files itself. This chapter lists a few tips and tricks. + </para> + <para> + Because these files are YUM Configuration files, you can configure anything that YUM supports. See <application>man yum.conf</application> for more details. + </para> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories-releasever_and_basearch"> + <title>$releasever and $basearch</title> + <para> + When configuring a repository URL, make sure you do not use <replaceable>$releasever</replaceable> or <replaceable>$basearch</replaceable> variables. Since Revisor allows cross-composing distributions between different versions of the operating system, as well as different architectures, these variables need to be expanded to the value intended. + </para> + <para> + See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories-Using_a_Local_Mirror"> + <title>Using a Local Mirror</title> + <para> + If you have a local mirror of Fedora, you can use the <literal>baseurl</literal> configuration directive in each repository configuration section to tell YUM to use the local mirror. + </para> + <para> + Optionally, you can also disable the <literal>mirrorlist</literal>, preferably by outcommenting it, so that YUM will only use the local mirror. + </para> + <para> + The default <literal>baseurl</literal> uses <literal>http://download.fedoraproject.org/</literal>. This location may or may not be suitable for you. If you have a local mirror, you might want to change this setting here, or add your mirror to Fedora Project's Mirrorlist. + </para> + <note> + <title>Adding your local mirror to the Mirrorlist</title> + <para> + You can add your local mirror to the Mirrorlist, so that the Fedora Project mirrorlist redirects you to your local mirror. Additionally, systems in your local network(s) will be redirected to the local mirror. The local mirror does not have to be a public mirror in order to do so. See <ulink url="http://admin.fedoraproject.org/mirrormanager/" /> for more details. + </para> + </note> + <para> + Set each <literal>baseurl</literal> to the location of the repository on the local mirror. + </para> + <para> + See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories-Using_Local_Files"> + <title>Using Local Files</title> + <para> + If you have the repositories on your local filesystem, configure a <literal>baseurl</literal> of <filename>file://<replaceable>/path/to/repository/</replaceable></filename>. + </para> + <note> + <title>Make sure to supply the correct path</title> + <para> + Make sure to supply the correct path to the repository. <filename>file://</filename> is the "<emphasis>protocol</emphasis>" for the location, and the location is <filename><replaceable>/path/to/repository/</replaceable></filename>. Put together, you have <emphasis>three</emphasis> slashes. + </para> + </note> + <para> + See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories-Using_a_DVD"> + <title>Using a DVD</title> + <para> + A DVD does not contain enough packages to rebuild the installer images. If you are using a DVD and you want to rebuild the installer images, you will need to have a network connection and a mirror you can reach. + </para> + <para> + There is a list of required packages, but since the packages change per release and may change in the middle of the release cycle as well, we cannot hand you a list that just works. + </para> + <para> + See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories-Adding_Third_Party_Repositories"> + <title>Adding Third Party Repositories</title> + <para> + When adding a third party repository, make sure you add the correct release version as well as architecture to the Revisor YUM configuration file. Verify the location for the <literal>baseurl</literal> and/or <literal>mirrorlist</literal> you configure manually or through YUM. Make sure you expand any <literal>$releasever</literal>, <literal>$basearch</literal> and <literal>$arch</literal> variables. + </para> + <para> + See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories-Creating_Your_Own_Repository"> + <title>Creating Your Own Repository</title> + <para> + Creating your own repository is relatively simple. You take a directory, dump some RPM packages in it, and run <application>createrepo</application>. See <literal>man createrepo</literal> for more information. + </para> + <para> + People often wonder how Revisor handles comps.xml group files. + </para> + <para> + When you create your own repository, follow the directions in <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Adding_Third_Party_Repositories" /> to add the repository configuration to Revisor's YUM configuration, since your own repository is a third party repository as well. + </para> + <para> + See also <xref linkend="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting" /> + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Yum_Repositories-Troubleshooting"> + <title>Testing & Troubleshooting the YUM Configuration</title> + <para> + Before you use the (modified) configuration file, take it for a test run. + </para> + </section> + + </section> + + <section id="Revisor_Documentation-Configuration-Configuring_A_Proxy"> + <title>Configuring A Proxy Server</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Configuration-Command-line_Options"> + <title>Command-line Options</title> + <para> + With the command-line options available, you can configure options that either override what is in the configuration file or have simply not been configured using the configuration file. With the default configuration files that come with the <application>revisor-cli</application> package for example, no media products have been pre-configured in the default section. In the <application>revisor-unity</application> package however, some default configuration has been applied so that Fedora Unity Re-Spins actually create CD, DVD and Rescue ISO images as well as the Installation Tree and include the sources. + </para> + <para> + Only some configuration options have CLI parameters. Use <application>revisor --help</application> to see a complete list of configuration options you can supply on the command line. + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Development.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Development.xml new file mode 100644 index 0000000..02407c1 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Development.xml @@ -0,0 +1,220 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Development"> + <title>Development</title> + <para> + This chapter sheds some light on development of Revisor, such as different branches and maintenance policies, versioning schemas, etcetera. + </para> + <para> + This part of the documentation relies on whether you have <application>sudo</application> set up properly. If you have not, you're on your own. + </para> + + <section id="Revisor_Documentation-Development-Running_Revisor_from_Source"> + <title>Running Revisor from Source</title> + <para> + The latest code in GIT can be built into a RPM you can install but one of the advantages of having the complete source tree is that you can run it directly from that source tree so that when you pull in the next updates you do not have to rebuild the RPM. Note that we do not bump the version number for every little change we make, and as such the RPM built does not allow you to use <literal>rpm -Uvh</literal> or <literal>rpm -Uvh --oldpackage</literal>. Of course, Revisor's Makefiles also allow <application>make install</application>, but that leaves a number of unmanaged files on your computer you would have to track down manually in order to remove Revisor completely. + </para> + <warning> + <title>Cannot have Revisor RPMs installed</title> + <para> + When running revisor from within the source tree, you cannot have any of the Revisor packages installed. Having Revisor RPM packages installed regardless will mess up the GIT repository or source tree. + </para> + </warning> + <para> + To run Revisor from within the source tree, checkout the master branch, and run the <filename>./switchhere</filename> script: + </para> + <para> + <screen>$ <userinput>./switchhere</userinput></screen> + </para> + <para> + The <filename>./switchhere</filename> script does the following: + </para> + <para> + <itemizedlist> + <listitem> + <para> + Symlink <filename>/etc/revisor/</filename> to <filename><replaceable>$PWD</replaceable>/conf/</filename> so that <filename>/etc/revisor/revisor.conf</filename>, the primary configuration file, and <filename>/etc/revisor/conf.d/</filename>, the configuration directory, are valid (the symlink causes the actual file and directory to be found in <filename><replaceable>$PWD</replaceable>/conf/</filename>) + </para> + </listitem> + <listitem> + <para> + Create the <filename>/usr/share/revisor/</filename> directory so that a couple of symlinks can be created from within that directory: + </para> + </listitem> + <listitem> + <para> + In Revisor 2.1.0 (development version in branch master), this includes: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/revisor/modgui/glade/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/revisor/modgui/glade/pixmaps/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + <listitem> + <para> + In Revisor 2.0.5 (branch F-7, F-8 or EL-5), this includes: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/usr/share/revisor/ui => <replaceable>$PWD</replaceable>/glade/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/pixmaps => <replaceable>$PWD</replaceable>/glade/pixmaps/</filename> + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/revisor/comps => <replaceable>$PWD</replaceable>/conf/</filename> + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + <listitem> + <para> + In Revisor 2.1.0, also create symlinks from within the appropriate <filename>/usr/share/man/man<replaceable>$x</replaceable>/</filename> directories to the source for these man pages in <filename><replaceable>$PWD</replaceable>/doc/</filename>. + </para> + </listitem> + </itemizedlist> + </para> + <para> + From this moment on, you should be able to run: + </para> + <para> + <screen>$ <userinput>./revisor.py</userinput></screen> + </para> + <note> + <title>Root privileges required</title> + <para> + Note that revisor needs root privileges to run, and that you'll need to sudo or su-c to gain those. Use here whatever you find the most convenient; Revisor though should have a nice error message when run without those privileges. + </para> + </note> + + <section id="Revisor_Documentation-Development-Running_Revisor_from_Source-Required_Packages"> + <title>Installing the Required Packages</title> + <para> + To be able to run Revisor from within the source tree, you'll need to install the required packages for each component, of course. + </para> + <para> + To get a current list of those packages, use: + </para> + <para> + <screen>$ <userinput>rpmquery --specfile --qf="%{REQUIRES}\n" revisor.spec | sort | uniq | xargs -n 1 repoquery --requires --alldeps --resolve</userinput></screen> + </para> + </section> + + </section> + + <section id="Revisor_Documentation-Development-Building_Revisor_Packages"> + <title>Building Revisor Packages</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Development-Tickets"> + <title>Tickets</title> + <para> + bugzilla, trac + </para> + </section> + + <section id="Revisor_Documentation-Development-Adding_A_New_Spin"> + <title>Adding a new spin or remix</title> + <para> + <orderedlist> + <listitem> + <para> + Add the appropriate models in the appropriate configuration file for Revisor. + </para> + </listitem> + <listitem> + <para> + Add the appropriate configuration file to the appropriate automake Makefile + </para> + </listitem> + <listitem> + <para> + Run autoreconf && ./configure && make rpm to verify the rpm building + </para> + </listitem> + <listitem> + <para> + Create the model's YUM configuration files with the following repositories: + </para> + <para> + <itemizedlist> + <listitem> + <para> + fedora, enabled, pointing to Everything + </para> + </listitem> + <listitem> + <para> + fedora-source, disabled, pointing to Everything + </para> + </listitem> + <listitem> + <para> + fedora-updates, enabled, pointing to the updates repository + </para> + </listitem> + <listitem> + <para> + fedora-updates-source, disabled, pointing to the updates repository + </para> + </listitem> + <listitem> + <para> + anaconda-updates, enabled, pointing to the anaconda updates repository + </para> + </listitem> + <listitem> + <para> + anaconda-updates-source, disabled, pointing to the ananconda updates repository + </para> + </listitem> + </itemizedlist> + </para> + </listitem> + </orderedlist> + </para> + </section> + + <section id="Revisor_Documentation-Development-Versioning_Schema"> + <title>Versioning Schema</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Development-Release_Procedure"> + <title>Release Procedure</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Features.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Features.xml new file mode 100644 index 0000000..6583398 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Features.xml @@ -0,0 +1,175 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Features"> + <title>Features</title> + <para> + Revisor allows you to build and customize your own Remix, Re-Spin, Spin or even your own distribution, based on Fedora and derivative distributions such as Red Hat Enterprise Linux and CentOS. + </para> + <para> + Revisor builds installation media, live media, installation trees, cobbler distro's and profiles, virtualization images and more. + </para> + + <section id="Revisor_Documentation-Features-Installation_Media"> + <title>Installation Media</title> + <para> + Installation media is what you use to install a system with. The installation media composed will allow you to go through the installation process, answering a number of questions (either manually or through kickstart), and ends up in a system running the distribution you install. + </para> + <para> + Composing installation media using the Revisor GUI allows you to choose the media (CD, or DVD), the packages to be included on the media (also called <emphasis>RPM payload</emphasis>). + </para> + <para> + Using the command-line interface, Revisor also allows you to choose DVD Duallayer and single- or dual-layer Bluray. + </para> + </section> + + <section id="Revisor_Documentation-Features-Installation_Trees"> + <title>Installation Trees</title> + <para> + Installation trees are typically used in environments where a distribution needs to be deployed over multiple systems, or is very volatile. Installation trees are often made accessible through HTTP or FTP protocols, in one place, and do not have as much overhead (in creating .iso files, and burning those to optical media to distribute them). + </para> + </section> + + <section id="Revisor_Documentation-Features-Live_Media"> + <title>Live Media</title> + <para> + Live media often is a perfect showcase for an Operating system, Desktop Environment or any other thing you want to show. Also, since Live media is read-only, live media perfectly allows for a kiosk system, a system that may change while it's running, but restores all original settings when rebooted. + </para> + <para> + Live media is also installable. You start out with a system and boot it from live media, then choose to install the live media. This however is inferior to real installation media, but is convenient if you happen to like what you see when running from live media. + </para> + </section> + + <section id="Revisor_Documentation-Features-Reproducibility"> + <title>Reproducibility</title> + <para> + Media composed with Revisor is extremely reproducible. Using <literal>kickstart_exact_nevra</literal>, you can even select specific versions of packages to be included on the product. + </para> + </section> + + <section id="Revisor_Documentation-Features-Consistency"> + <title>Consistency</title> + <para> + When composing different types of media, such as CDs and DVDs, Revisor composes these discs in one run, making the different media completely consistent. <application>pungi</application> would require you to run twice, once for CDs, and once for DVDs. This is because <application>pungi</application> uses the <literal>part / <replaceable><size></replaceable></literal> kickstart configuration directive to set the maximum size of the media, and has no option to override the size on the command-line, nor to compose a certain set of media (it all depends on the size). + </para> + </section> + + <section id="Revisor_Documentation-Features-Flexibility"> + <title>Flexibility</title> + <para> + Over the years, Revisor has been adopted to serve a large number of use-cases, where use-cases stretch from media being composed as efficient as possible, as robust as possible, specific deployment needs and expectations, and to match the Fedora Project Release Engineering tools' behaviour. All this allows you to configure a lot, and thus customize a lot, making Revisor more of a flexible framework. + </para> + </section> + + <section id="Revisor_Documentation-Features-Graphical_User_Interface"> + <title>Graphical User Interface</title> + <para> + Revisor has a Graphical User Interface or GUI, in addition to the Command Line Interface or CLI, which makes Revisor more accessible to users then the other tools, which are CLI only. Most people only know of Revisor through the GUI, and may think there is no CLI to Revisor. Only when it comes down to many of the additional features that Revisor has, and that do not fit in a simplified GUI, one gets down with it using the CLI. + </para> + </section> + + <section id="Revisor_Documentation-Features-Open_Development_Community"> + <title>Open Development Community</title> + <para> + Revisor has one of those old-fashioned Free and Open Source Software development communities, allowing anyone to make a contribution to Revisor. In fact, Revisor has not bounced a single patch since the project started. Therefor, it improves faster then any of the other compose tools, and is better adaptible to your needs and expectations, because unlike the other utilities, Revisor is not limited to use-cases that apply to Fedora Project Release Engineering. + </para> + </section> + + <section id="Revisor_Documentation-Features-Plugin_System"> + <title>Plugin System</title> + <para> + Revisor has a plugin system so that you can easily extend Revisor. This plugin system gives you full control over the Revisor procedures, and hands you off anything Revisor knows about the compose process. There's are multiple plugins available from upstream as well. To give you an example, the ability to replace <filename>isolinux.cfg</filename> after the compose is done, is a plugin. See <xref linkend="Revisor_Documentation-Plugins" /> for more information. + </para> + + <para> + Current plugins included with Revisor include: + </para> + <para> + <itemizedlist> + <listitem> + <para> + <xref linkend="Revisor_Documentation-Plugins-Upstream-Cobbler_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Documentation-Plugins-Upstream-Isolinux_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Documentation-Plugins-Upstream-Rebrand_Plugin" /> + </para> + </listitem> + <listitem> + <para> + <xref linkend="Revisor_Documentation-Plugins-Upstream-Reuse_Installer_Images_Plugin" /> + </para> + </listitem> + </itemizedlist> + </para> + </section> + + <section id="Revisor_Documentation-Features-Extraneous_Debugging"> + <title>Extraneous Debugging</title> + <para> + Revisor has extraneous debugging, which enables you, as well as the supporters and Revisor's developers, to trace down what happens exactly, and where anything might go wrong. + </para> + </section> + + <section id="Revisor_Documentation-Features-Using_YUM_Configuration_Files"> + <title>Using YUM Configuration Files</title> + <para> + Revisor uses YUM configuration files, where everyone else is not. With using YUM configuration files however, the control you have is nearly limitless. With all the features in YUM already, using it's configuration file format and letting YUM itself work with those allows Revisor to do a lot of cool things without doing anything itself: + </para> + <para> + <orderedlist> + <listitem> + <formalpara> + <title>Excluding packages from repositories</title> + <para> + Excluding packages from repositories means a great deal. Not having them exist in the <xref linkend="Revisor_Documentation-Appendix-Terminology-Package_Sack" /> ensures the package will not end up in the product. This may be what you want for maybe just a few, or maybe an awful lot of packages. + </para> + </formalpara> + <para> + Using the alternative configuration file format, kickstart, in use by every other compose tool, and the <literal>repo</literal> configuration directive that is available with kickstart, you can exclude packages using the <literal>--exclude=</literal> parameter to the <literal>repo</literal> configuration directive. However, that parameter does not allow wildcard matches. + </para> + </listitem> + <listitem> + <formalpara> + <title>Including only a certain (set of) package(s)</title> + <para> + Including only a certain package, or certain set of packages is valuable when a lot of packages exist in the repository configured, but you only need one or two. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Concurrent use of baseurl(s) and the mirrorlist</title> + <para> + Like during normal YUM operations, the baseurl(s) and the mirrorlist configured for a repository are used concurrently. This is not possible with the kickstart configuration directive <literal>repo</literal>, which takes either <literal>--baseurl</literal> or <literal>--mirrorlist</literal>, but not both. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>Repository priorities</title> + <para> + Settings available with YUM are available within Revisor as well, like repository priorities. Using repository priorities, you can have YUM decide to pull a package from the repository with a higher priority (a lower priority number) rather then a repository with a lower priority. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title>YUM Plugins</title> + <para> + YUM plugins, such as <application>yum-fastestmirror</application>, <application>yum-fedorakmod</application>, are available, giving you even more control over the behaviour of YUM. + </para> + </formalpara> + </listitem> + </orderedlist> + </para> + </section> +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml new file mode 100644 index 0000000..489d42a --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml @@ -0,0 +1,54 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Frequently_Asked_Questions"> + <title>Frequently Asked Questions</title> + <para> + para + </para> + + <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-How_Does_Revisor_Handle_Comps"> + <title>How Does Revisor Handle Comps?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-What_Are_Installer_Images"> + <title>What Are Installer Images?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Pungi"> + <title>What is the relationship between Revisor and Pungi?</title> + <para> + Where pungi builds a bunch of RPMs into ISO images and installation trees through one single procedure, perfect for Release Engineering on something like the Fedora Project, Revisor does it different entirely. + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-Relationship_Between_Revisor_and_Livecd-tools"> + <title>What is the relationship between Revisor and livecd-tools?</title> + <para> + Revisor depends on livecd-tools for the composing of live media. Creating the filesystem to install the packages to, turning that image file into a SquashFS file, and applying the settings inside the chroot. + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-Why_Rebuild_Installer_Images"> + <title>Why Rebuild Installer Images?</title> + <para> + para + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Frequently_Asked_Questions-How_do_I_create_an_updates.img"> + <title>How do I create an updates.img?</title> + <para> + para + </para> + </formalpara> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Installation.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Installation.xml new file mode 100644 index 0000000..9997088 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Installation.xml @@ -0,0 +1,104 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Installation"> + <title>Installation</title> + <para> + This chapter contains the installation instructions for Revisor. + </para> + + <section id="Revisor_Documentation-Installation-Packages"> + <title>Packages</title> + <para> + You can install Revisor using RPM packages from the repositories already configured on your system. + </para> + + <formalpara id="Revisor_Documentation-Installation-Packages-revisor"> + <title><application>revisor</application></title> + <para> + Shorthand package for the Revisor GUI. + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Installation-Packages-revisor-cli"> + <title><application>revisor-cli</application></title> + <para> + The CLI version of Revisor. This package is always installed, as it contains the Python code for Revisor's core. Installing just this package will give you the command-line version of Revisor, and prevents the graphical dependencies from the <xref linkend="Revisor_Documentation-Installation-Packages-revisor-gui" /> package to be installed as well. + </para> + </formalpara> + + <formalpara id="Revisor_Documentation-Installation-Packages-revisor-gui"> + <title><application>revisor-gui</application></title> + <para> + The GUI version of Revisor. This is the actual package containing the Graphical User Interface, as opposed to <xref linkend="Revisor_Documentation-Installation-Packages-revisor" />. Depends on <xref linkend="Revisor_Documentation-Installation-Packages-revisor-cli" />, and thus also installs the command-line version of Revisor. + </para> + </formalpara> + + <section id="Revisor_Documentation-Installation-Packages-YUM-RHEL"> + <title>Red Hat Enterprise Linux 5 or higher</title> + <para> + On Red Hat Enterprise Linux 5 or higher, and derivatives, install the Extra Packages for Enterprise Linux (EPEL) repository. + </para> + <para> + Then, give the following command: + </para> + <para> + <screen># <userinput>yum install revisor</userinput></screen> + </para> + </section> + + <section id="Revisor_Documentation-Installation-Packages-YUM-Fedora"> + <title>Fedora 7 or higher</title> + <para> + On Fedora 7 or higher, and derivatives, no additional repository configuration is required. + </para> + <para> + Give the following command: + </para> + <para> + <screen># <userinput>yum install revisor</userinput></screen> + </para> + <note> + <title>About EOL Releases</title> + <para> + Please bear in mind that Fedora releases that are past the point of End-Of-Life, approximatly 13 months after the initial release, are not supported anymore for use with Revisor. Also, the version of Revisor running on these EOL versions of Fedora are not supported anymore. + </para> + </note> + </section> + + </section> + + <section id="Revisor_Documentation-Installation-The_Latest_And_Greatest"> + <title>The Latest and Greatest</title> + <para> + The latest and greatest is available from GIT, at <ulink url="git://git.fedorahosted.org/revisor" />. To clone this repository, use: + </para> + <para> + <screen>$ <userinput>git clone git://git.fedorahosted.org/revisor/</userinput></screen> + </para> + <para> + Using the GIT clone, you have the several options to start using the latest and greatest: + </para> + <formalpara> + <title>Running directly from the source</title> + <para> + You can run directly from within the source tree. See <xref linkend="Revisor_Documentation-Development-Running_Revisor_from_Source" /> for more information on how to do so. + </para> + </formalpara> + <warning> + <title>Installed packages and running from source</title> + <para> + Do not run Revisor from source while RPM packages have been installed. Files managed by a package will get created, moved and removed when using Revisor's source tree, and updates to the installed RPM packages will destroy these changes. + </para> + </warning> + <formalpara> + <title>Building your own packages</title> + <para> + You can create your own packages, so that you have all the benefits of RPM. See <xref linkend="Revisor_Documentation-Development-Building_Revisor_Packages" /> for more information on how to do so. + </para> + </formalpara> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Introduction.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Introduction.xml new file mode 100644 index 0000000..465fbf2 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Introduction.xml @@ -0,0 +1,71 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Introduction"> + <title>Introduction</title> + <para> + Revisor is a community product by Fedora Unity. Amongst other features, it allows the creation of installation media and live media in the easiest possible manner, through a click-and-go GUI. This chapter gives some insight on how and why Revisor was born, and how the product evolved since. + </para> + + <section id="Revisor_Documentation-Introduction-History_Of_Revisor"> + <title>History of Revisor</title> + <para> + Revisor development started in December 2006, during the Fedora 7 development cycle, in which -you might recall- the Fedora Core repository, maintained by Red Hat, and Fedora Extras repository, mostly maintained by the community, were merged into one large repository being maintained by both community members as well as Red Hat employees -which are mostly community members hired by Red Hat -so community altogether. Before then Red Hat employees maintained Fedora Core -as the set of packages upstream for Red Hat's Enterprise product- and the community maintained a repository with additional software; Fedora Extras. Red Hat composed the Fedora distribution every once in a while, but the merge introduced the possibility for packages that were in Fedora Extras to be included in the main distribution, and for the community to also (co-)maintain the (former) Fedora Core packages that originally made up the distribution. + </para> + <para> + In addition to this huge merge of packages, Red Hat employees were also able to release the entire build process to the community, meaning that from the moment the source is committed up and until the release is announced, the entire process is open. Not that is was all behind closed doors or proprietary or anything, the community just couldn't really play with it as much. We now have koji (build system), mash (repository compose from build system products), bodhi (updates release system), livecd-tools (compose tool for live media) and pungi (compose tool for installation media). + </para> + <para> + Composing media was an obscure process up and until the moment these tools exposed the best way to compose (a set of) installation media. Fedora Unity had been building and releasing so-called Re-Spins1 regularly, but they were built using a not-so-very intelligent bash script. Like hundreds if not thousands of other parties that needed to build their own media one way or the other, the entire process was based on the best educated guess of what should happen. Luckily, in the FOSS world an educated guess is often a very good guess, despite the fact that one keeps learning even years after the original engagement. + </para> + <para> + When in December 2006 the compose tools hit a stage in which they were released to the public, Fedora Unity was eager to get these tools and study them and use them for composing their Re-Spins. Up and until then, Re-Spins were composed with the aforementioned bash script that didn't do much but trigger the appropriate commands in a sequence; There wasn't any dependency resolving between the packages included nor did we know exactly how a release was supposed to be composed -it was our educated guess of how it could happen. Although it often led to success, we've had many, many failed Re-Spins as well. With a handful of volunteers, you can imagine the amount of frustration that might give. Fedora Unity was eager to improve their Re-Spin process. + </para> + <para> + So, early February 2007, a number of Fedora Unity members attended “FUDCon 2007” in Boston, and presented a working GUI front-end to livecd-tools and pungi enabling regular users to also re-compose or re-spin the installation media and live media they had been getting from the Fedora Project. Revisor at this point just made it “as easy as possible”. Besides the possibilities of pungi and livecd-tools themselves, the wizard Revisor had apparently was very, very useful to mere mortals. From that point on, things took off. + </para> + <para> + Fedora Unity decided Revisor could accomplish more then just being a front-end to existing compose tools and enable someone to tweak a lot of settings as well. In March 2007, Revisor was rebuild from the ground up in March 2007 to allow a more flexible process, more dependent on the configuration directives it was given and less so on the processes of the existing tools. When in San Diego at the Red Hat Summit (early May 2007), Robert 'Bob' Jensen and Jonathan Steffan gave a presentation on “Customizing Fedora”, the responses were amazing. Since then Revisor has evolved from a front-end to existing tools to the complete compose tool it is today, with lots of configuration options for specific use-cases. + </para> + <para> + For users, Revisor is particularly useful because it has a GUI front-end wizard, which, with the defaults settings, will just succeed in getting a user the media he/she wants. If a user decides he needs little adjustment of the media, the GUI allows for selecting the most common options. If a user decides he needs some less common adjustments, the configuration options gives him very granular control -and as long as the documentation on all the options is sufficient, users will be able to make those less common adjustments. + </para> + <para> + For administrators on the other hand, Revisor is the tool that gives so much granular control over what happens, that it can serve almost every specific use-case. In this aspect, Revisor could potentially replace the compose tools administrators have been developing themselves with a consistent and flexible program flow. + </para> + <para> + This document should enable you to study the process of composing installation and live media, and comprehend the logic Revisor adds to that process. + </para> + </section> + + <section id="Revisor_Documentation-Introduction-The_Installation_Media_Challenge"> + <title>The Installation Media Challenge</title> + <para> + When Fedora Unity first started doing these so-called Re-Spins, the challenge ahead could maybe be explained like this: + </para> + <para> + <emphasis>When a user downloads a Fedora release and installs the distribution, the user will need to download and install a number of updates. The “older” the release becomes, the more updates will be available, and the greater the total download size of these updates the user will need to download on top of the download size of the original release media.</emphasis> + </para> + <para> + “older” is in quotes on purpose, because really for an operating system -or “distribution” if you will- being released every 6 months, “old” is quite a relative concept. The number of updates available however, at any given time during the release cycle, may range from 0 right after the release (which has never happened before), to the total amount of packages installed on the user's system (often over 2000). You can imagine the size of these updates ranging from 0 MB to an astonishing 2GB(!), only 6 months after the initial release. + </para> + <para> + Some of us do not have the bandwidth capacity or enough data transfer quota to download this many extra, rather useless bits. In addition, some of us do not have an Internet connection at all, and thus benefit getting the updates from Re-Spins directly. + </para> + <para> + The use of updates in Re-Spins has several more beneficial side-effects, which we'll explain in more detail later on in this document. Long story short; If for some reason the software used to compose the media (the release) with does not work for your hardware or your specific needs, updated software incorporated in the composed installer images might resolve that problem. + </para> + <para> + This is the original challenge the Fedora Unity team resolved a long time ago, and is at the base of what Revisor does nowadays. + </para> + </section> + + <section id="Revisor_Documentation-Introduction-The_Live_Media_Challenge"> + <title>The Live Media Challenge</title> + <para> + Back in the day Fedora Core 5 was the most recent release, Fedora Unity created so-called live media using Kadischi. In that time, live media could only have a read-only root file system and was not as feature-rich as live media is today. However, just before Revisor came to life, two applications were developed; pungi for creating installation media, and livecd-tools for creating live media. These two applications did their work well; The media composed for a release, including many different custom live media spins were, and still are, created with these tools. Immediately, the Revisor developers set themselves a target to provide a single interface to both of those tools. + </para> + </section> + +</chapter> diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Plugins.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Plugins.xml new file mode 100644 index 0000000..adcca82 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Plugins.xml @@ -0,0 +1,131 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Plugins"> + <title>Plugins</title> + <para> + para + </para> + + <section id="Revisor_Documentation-Plugins-Upstream"> + <title>Upstream Plugins</title> + <para> + Plugins available from upstream, maintained by upstream + </para> + + <section id="Revisor_Documentation-Plugins-Upstream-Cobbler_Plugin"> + <title>Cobbler Plugin</title> + <para> + The Cobbler plugin is able to put the product composed into a Cobbler environment, by handing off the built product to the existing Cobbler infrastructure as a <emphasis>distro</emphasis>, and creating a <emphasis>profile</emphasis>. + </para> + <para> + Using this module, one can automatically import the Revisor product into a Cobbler environment, and immediately use the new Cobbler <emphasis>profile</emphasis> to start deploying or automated testing, maybe. + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Composer_Plugin"> + <title>Composer Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Delta_Plugin"> + <title>Delta Plugin</title> + <para> + A small change to a ISO image does not require you to download the complete ISO image if you have a copy of the old ISO image. + </para> + <note> + <title>Only applicable to (...)</title> + <para> + The generation of Delta ISO images is only applicable to situations in which the ISO image does not contain SquashFS images. SquashFS images are smaller, but all SquashFS images are unique. Since the Delta principle is based on similarities, and no two SquashFS images are alike, creating a Delta on two ISO images containing SquashFS images will lead to a Delta pratically the same size as the SquashFS image. For Live Media that compresses the ext3 filesystem image into a SquashFS image, since that SquashFS image is probably over 97% of the size of the ISO image, creating Delta images for compressed Live Media does not make sense. For installation media however, most RPMs would be similar as well as (potentially) the installer images. + </para> + </note> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-GUI_Plugin"> + <title>GUI (Graphical User Interface) Plugin</title> + <para> + Yes, the Graphical User Interface for Revisor is actually a plugin. + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-HUB_Plugin"> + <title>HUB Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Isolinux_Plugin"> + <title>Isolinux Plugin</title> + <titleabbrev id="Isolinux_Plugin">Isolinux Plugin</titleabbrev> + <para> + The isolinux plugin adds the <literal>--isolinux-cfg</literal> command-line option to Revisor. Specify a file here, and the original <filename>isolinux.cfg</filename> that is built as part of the compose process is replaced by the <filename>isolinux.cfg</filename> specified. + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Jigdo_Plugin"> + <title>Jigdo Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Mock_Plugin"> + <title>Mock Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Rebrand_Plugin"> + <title>Rebrand Plugin</title> + <para> + The rebrand plugin hooks in to Revisor at several different stages. The goal of this plugin is to ensure no trademarked packages end up on the media. Trademarked packages may include <application>fedora-logos</application>, <application>redhat-logos</application>, and so forth. + </para> + <para> + The plugin adds a <literal>--rebrand</literal> option, to which you can specify the name of your new product. When rebranding Fedora to Omega for example, specifying <literal>--rebrand Omega</literal> would be sufficient to make sure the product does not have any Fedora trademarks. + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Reuse_Installer_Images_Plugin"> + <title>Reuse Installer Images Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Server_Plugin"> + <title>Server Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-Virtualization_Plugin"> + <title>Virtualization Plugin</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Plugins-Upstream-WUI_Plugin"> + <title>WUI (Web-based User Interface) Plugin</title> + <para> + para + </para> + </section> + + </section> + + <section id="Revisor_Documentation-Plugins-Writing_Your_Own"> + <title>Writing Your Own Plugins</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Testing.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Testing.xml new file mode 100644 index 0000000..2450faf --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Testing.xml @@ -0,0 +1,173 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Testing"> + <title>Testing</title> + <para> + The following test cases describe different types of testing a new Revisor release. + </para> + + <section id="Revisor_Documentation-Testing-Simple_Test_Cases"> + <title>Simple Test Cases</title> + <para> + This section has a few simple test cases ensuring configuration shipped with Revisor works as anticipated. + </para> + + <section id="Revisor_Documentation-Testing-Simple_Test_cases-Packages"> + <title>Packages</title> + <para> + Install the <application>revisor-cli</application>: + </para> + <para> + <screen># <userinput>yum --enablerepo=updates-testing install revisor</userinput></screen> + </para> + <para> + Installed are all dependencies for the Revisor CLI interface. Make sure <application>spin-kickstarts</application> is installed, a package for sample kickstarts. + </para> + <para> + Starting Revisor as follows should not show any error messages related to Revisor attempting to start up it's GUI interface: + </para> + <para> + <screen># <userinput>revisor</userinput></screen> + </para> + + <formalpara> + <title>Configuration Files</title> + <para> + The following configuration files should exist: + </para> + </formalpara> + <para> + <itemizedlist> + <listitem> + <para> + <filename>/etc/revisor/revisor.conf</filename> + </para> + </listitem> + </itemizedlist> + </para> + <para> + Each section should have a configuration file listed as <literal>main</literal>. + </para> + <para> + And, of course, every configuration file listed in each section. In this case, the following snippet is easy enough: + </para> + <para> + <screen>$ <userinput>i=0; \ +configfiles="`grep ^main /etc/revisor/revisor.conf | \ + sed -r -e 's/^main.*=\s*(.*)/\1/g'`" + +for configfile in $configfiles; do \ + [ ! -f $file ] && i=1; \ +done; \ +echo $i</userinput></screen> + </para> + <para> + Another way to test the configuration file is to execute: + </para> + <para> + <screen>$ <userinput>revisor --list-models >/dev/null</userinput></screen> + </para> + <para> + If everything is well, since <literal>STDOUT</literal> is redirected to <filename>/dev/null</filename>, you should see no messages at all. + </para> + + </section> + + <section id="Revisor_Documentation-Testing-Simple_Test_Cases-Configuration_Files"> + <title>Configuration Files</title> + <para> + The main Revisor configuration file is <filename>/etc/revisor/revisor.conf</filename>. The file lists a series of models, each having their own YUM configuration file in <filename>/etc/revisor/conf.d/</filename>. + </para> + <formalpara> + <title>Testing</title> + <para> + <itemizedlist> + <listitem> + <para> + For each model in <filename>/etc/revisor/revisor.conf</filename>, the <code>main</code> setting for that model should point to a valid file. + </para> + </listitem> + <listitem> + <para> + Each YUM configuration file should work. To verify, run the following command for each configuration file: + </para> + <para> + <screen>$ yum -c <replaceable>$file</replaceable> list kernel</screen> + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>Known Errors</title> + <para> + <itemizedlist> + <listitem> + <para> + Revisor has baseurls in YUM repositories set to <ulink url="http://localrepo" />. This URL will not be retrievable for many people, but allows the developers to quickly change mirrors. + </para> + </listitem> + <listitem> + <para> + Repositories that are unavailable at the moment of testing will throw errors Revisor can't do anything about. + </para> + </listitem> + <listitem> + <para> + If the directories <filename>revisor-yumcache/</filename> and <filename>revisor/</filename> in <filename>/var/tmp/</filename>, the default working directory, are not writeable for the user then YUM will throw permission denied errors. + </para> + <para> + Remove <filename>/var/tmp/revisor/</filename> and <filename>/var/tmp/revisor-yumcache/</filename> or run the command with root permissions. + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + </section> + + <section id="Revisor_Documentation-Testing-Simple_Test_Cases-Compose_Results"> + <title>Requirements for Compose Results</title> + <para> + Although heavily dependent on Anaconda for this part, these are still requirements + </para> + + <formalpara> + <title>ld-linux.so.2</title> + <para> + In the <filename>initrd.img</filename> of the composed product, if 32-bit, <filename>/lib/ld-linux.so.2</filename> (or any other version) should link to <filename>/lib/ld-2.9.so</filename> (or any other version). If <filename>/lib/ld-linux.so.2</filename> links to itself, the media will fail to install. + </para> + </formalpara> + <formalpara> + <title>How to test</title> + <para> + In a terminal, type the following command: + </para> + </formalpara> + <para> + <screen>$ <userinput>lsinitrd /path/to/initrd | grep ld-linux</userinput></screen> + </para> + <para> + See also: <ulink url="https://www.redhat.com/archives/anaconda-devel-list/2009-February/msg00115.…" /> + </para> + + </section> + </section> + + <section id="Revisor_Documentation-Testing-Complex_Test_Cases"> + <title>Complex Test Cases</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Testing-Specific_Test_Cases"> + <title>Specific Test Cases</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Tips_and_Tricks.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Tips_and_Tricks.xml new file mode 100644 index 0000000..488a957 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Tips_and_Tricks.xml @@ -0,0 +1,47 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Tips_and_Tricks"> + <title>Tips and Tricks</title> + <para> + para + </para> + + <section id="Revisor_Documentation-Tips_and_Tricks-The_spin-kickstarts_Package"> + <title>The spin-kickstarts Package</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Tips_and_Tricks-Even_More_Debugging"> + <title>Even More Debugging</title> + <para> + something about using -x to buildinstall scripts + </para> + </section> + + <section id="Revisor_Documentation-Tips_and_Tricks-ksvalidator"> + <title>Kickstart Validator</title> + <para> + something about using -x to buildinstall scripts + </para> + </section> + + <section id="Revisor_Documentation-Tips_and_Tricks-Using_Mirrormanager_For_Mirror_Redirection"> + <title>Using Mirrormanager for Mirror Redirection</title> + <para> + Something about using Mirrormanager to redirect you to the local mirror (so you do not have to edit YUM configuration files). + </para> + </section> + + <section id="Revisor_Documentation-Tips_and_Tricks-The_localrepo_DNS_Alias"> + <title>Using The localrepo DNS Alias</title> + <para> + Something about using the localrepo DNS alias to point to your local mirror (either through real DNS or through /etc/hosts), so you do not have to edit the YUM configuration files. + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Tweaking_The_Build_Process.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Tweaking_The_Build_Process.xml new file mode 100644 index 0000000..d095289 --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Tweaking_The_Build_Process.xml @@ -0,0 +1,40 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Tweaking_The_Build_Process"> + <title>Tweaking the build process</title> + <para> + para + </para> + + <section id="Revisor_Documentation-Tweaking_The_Build_Process-Reusing_Existing_Installer_Images"> + <title>Reusing Existing Installer Images</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Tweaking_The_Build_Process-Building_The_Installer_Images_In_Mock"> + <title>Building The Installer Images in Mock</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Tweaking_The_Build_Process-Omitting-isomd5sum"> + <title>Omitting isomd5sums</title> + <para> + para + </para> + </section> + + <section id="Revisor_Documentation-Tweaking_The_Build_Process-Omitting-sha1sums"> + <title>Omitting SHA1SUMS</title> + <para> + para + </para> + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/Revisor_Documentation-Using_Kickstart.xml b/doc/Reference_Manual/en-US/Revisor_Documentation-Using_Kickstart.xml new file mode 100644 index 0000000..7575bea --- /dev/null +++ b/doc/Reference_Manual/en-US/Revisor_Documentation-Using_Kickstart.xml @@ -0,0 +1,118 @@ +<?xml version='1.0'?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> + +<chapter id="Revisor_Documentation-Using_Kickstart"> + <title>Using Kickstart</title> + <para> + Kickstart is a configuration file format for automating installation procedures. Or at least, it was, originally. Nowadays, kickstart files are used as input to the compose tools, including Revisor. + </para> + <para> + Revisor again is unique in that it does not require a kickstart file for input. The other tools only take kickstart configuration files. Revisor though allows most of what is in a kickstart file to be configured interactively in Graphical User Interface mode. + </para> + + <section id="Revisor_Documentation-Using_Kickstart-How_Kickstart_Is_Used"> + <title>How Kickstart Is Used</title> + <para> + There's two cases in which a kickstart file is used differently. One is during the compose of installation media, and the other of course is during the compose of live media, or virtualization media. + </para> + + <section id="Revisor_Documentation-Using_Kickstart-How_Kickstart_Is_Used-Installation_Media"> + <title>Installation Media</title> + <para> + In the case of installation media, the following settings are used: + </para> + <para> + <itemizedlist> + <listitem> + <formalpara> + <title><literal>repo</literal></title> + <para> + The <literal>repo</literal> command in kickstart is used when Revisor is configured to use the repositories configured in the kickstart file only. Use <literal>kickstart_repos = 1</literal> to enable this feature, or set the appropriate checkbox in the Revisor GUI. + </para> + </formalpara> + </listitem> + <listitem> + <formalpara> + <title><literal>%packages</literal></title> + <para> + The <literal>%packages</literal> section in kickstart is used to determine the RPM payload on the installation media. It can include groups and packages, and exclude packages. It accepts wildcards, both in includes and excludes of packages (but not groups). + </para> + </formalpara> + </listitem> + </itemizedlist> + </para> + <note> + <title>@core and @base</title> + <para> + By default, groups @core and @base are included in the package manifest. You can specify @base to not be included, by using <literal>%packages --nobase</literal>, but @core cannot be excluded using a kickstart package manifest. + </para> + </note> + <para> + Using <literal>kickstart_exact</literal>, you can exclude @core and @base so that you need to explicitly select them in the kickstart package manifest. + </para> + <para> + Using <literal>kickstart_exact_nevra</literal> ... + </para> + </section> + </section> + + <section id="Revisor_Documentation-Using_Kickstart-The_Kickstart_Package_Manifest"> + <title>The Kickstart Package Manifest</title> + <para> + para + </para> + + <formalpara> + <title>Group @core</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Group @base</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Including groups of packages</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Including a single package</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Excluding a single package</title> + <para> + para + </para> + </formalpara> + + <formalpara> + <title>Using wildcard matches</title> + <para> + para + </para> + </formalpara> + + <section id="Revisor_Documentation-Using_Kickstart-Using_Kickstart_With_Package_NEVRA"> + <title>Using Kickstart with Package NEVRA</title> + <para> + para + </para> + </section> + + </section> + +</chapter> + diff --git a/doc/Reference_Manual/en-US/images/icon.svg b/doc/Reference_Manual/en-US/images/icon.svg new file mode 100644 index 0000000..c471a60 --- /dev/null +++ b/doc/Reference_Manual/en-US/images/icon.svg @@ -0,0 +1,3936 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> + +<svg + xmlns:ns="http://ns.adobe.com/AdobeSVGViewerExtensions/3/" + xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/" + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://web.resource.org/cc/" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:xlink="http://www.w3.org/1999/xlink" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + version="1.0" + width="32" + height="32" + id="svg3017" + sodipodi:version="0.32" + inkscape:version="0.44+devel" + sodipodi:docname="book.svg" + sodipodi:docbase="/home/andy/Desktop"> + <metadata + id="metadata489"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + </cc:Work> + </rdf:RDF> + </metadata> + <sodipodi:namedview + inkscape:window-height="480" + inkscape:window-width="858" + inkscape:pageshadow="0" + inkscape:pageopacity="0.0" + guidetolerance="10.0" + gridtolerance="10.0" + objecttolerance="10.0" + borderopacity="1.0" + bordercolor="#666666" + pagecolor="#ffffff" + id="base" + inkscape:zoom="1" + inkscape:cx="16" + inkscape:cy="15.944056" + inkscape:window-x="0" + inkscape:window-y="33" + inkscape:current-layer="svg3017" /> + <defs + id="defs3019"> + <linearGradient + id="linearGradient2381"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="stop2383" /> + <stop + style="stop-color:white;stop-opacity:0" + offset="1" + id="stop2385" /> + </linearGradient> + <linearGradient + x1="415.73831" + y1="11.854" + x2="418.13361" + y2="18.8104" + id="XMLID_1758_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.8362,0.5206,-1.1904,0.992,147.62,-30.9374)"> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="0" + id="stop3903" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="1" + id="stop3905" /> + <a:midPointStop + style="stop-color:#CCCCCC" + offset="0" /> + <a:midPointStop + style="stop-color:#CCCCCC" + offset="0.5" /> + <a:midPointStop + style="stop-color:#F2F2F2" + offset="1" /> + </linearGradient> + <linearGradient + x1="500.70749" + y1="-13.2441" + x2="513.46442" + y2="-2.1547" + id="XMLID_1757_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0" + id="stop3890" /> + <stop + style="stop-color:#96bad6;stop-opacity:1" + offset="1" + id="stop3892" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#96BAD6" + offset="1" /> + </linearGradient> + <clipPath + id="XMLID_1755_"> + <use + id="use3874" + x="0" + y="0" + width="744.09448" + height="600" + xlink:href="#XMLID_343_" /> + </clipPath> + <linearGradient + x1="505.62939" + y1="-14.9526" + x2="527.49402" + y2="-0.7536" + id="XMLID_1756_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0" + id="stop3877" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0.51120001" + id="stop3879" /> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0.64609998" + id="stop3881" /> + <stop + style="stop-color:#16336e;stop-opacity:1" + offset="1" + id="stop3883" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5112" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.6461" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#16336E" + offset="1" /> + </linearGradient> + <linearGradient + x1="471.0806" + y1="201.07761" + x2="481.91711" + y2="210.4977" + id="XMLID_1754_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#6498c1;stop-opacity:1" + offset="0.005618" + id="stop3863" /> + <stop + style="stop-color:#79a9cc;stop-opacity:1" + offset="0.2332" + id="stop3865" /> + <stop + style="stop-color:#a4cde2;stop-opacity:1" + offset="0.74049997" + id="stop3867" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="1" + id="stop3869" /> + <a:midPointStop + style="stop-color:#6498C1" + offset="5.618000e-003" /> + <a:midPointStop + style="stop-color:#6498C1" + offset="0.4438" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="1" /> + </linearGradient> + <linearGradient + x1="516.57672" + y1="-15.769" + x2="516.57672" + y2="0.84280002" + id="XMLID_1753_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0" + id="stop3851" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="1" + id="stop3853" /> + <a:midPointStop + style="stop-color:#B2B2B2" + offset="0" /> + <a:midPointStop + style="stop-color:#B2B2B2" + offset="0.5" /> + <a:midPointStop + style="stop-color:#F2F2F2" + offset="1" /> + </linearGradient> + <clipPath + id="XMLID_1751_"> + <use + id="use3837" + x="0" + y="0" + width="744.09448" + height="600" + xlink:href="#XMLID_338_" /> + </clipPath> + <linearGradient + x1="506.09909" + y1="-11.5137" + x2="527.99609" + y2="2.7063999" + id="XMLID_1752_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0" + id="stop3840" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0.51120001" + id="stop3842" /> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0.64609998" + id="stop3844" /> + <stop + style="stop-color:#16336e;stop-opacity:1" + offset="1" + id="stop3846" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5112" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.6461" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#16336E" + offset="1" /> + </linearGradient> + <linearGradient + x1="468.2915" + y1="204.7612" + x2="479.39871" + y2="214.4166" + id="XMLID_1750_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0" + id="stop3830" /> + <stop + style="stop-color:#96bad6;stop-opacity:1" + offset="1" + id="stop3832" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#96BAD6" + offset="1" /> + </linearGradient> + <linearGradient + x1="502.70749" + y1="115.3013" + x2="516.39001" + y2="127.1953" + id="XMLID_1749_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9703,0.2419,-0.2419,0.9703,11.0227,-35.6159)"> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0" + id="stop3818" /> + <stop + style="stop-color:#96bad6;stop-opacity:1" + offset="1" + id="stop3820" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#96BAD6" + offset="1" /> + </linearGradient> + <linearGradient + x1="501.0903" + y1="-19.2544" + x2="531.85413" + y2="0.72390002" + id="XMLID_1748_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0" + id="stop3803" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0.51120001" + id="stop3805" /> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0.64609998" + id="stop3807" /> + <stop + style="stop-color:#16336e;stop-opacity:1" + offset="1" + id="stop3809" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5112" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.6461" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#16336E" + offset="1" /> + </linearGradient> + <linearGradient + x1="481.23969" + y1="212.5742" + x2="472.92981" + y2="207.4967" + id="XMLID_2275_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#f3403f;stop-opacity:1" + offset="0" + id="stop9947" /> + <stop + style="stop-color:#d02a28;stop-opacity:1" + offset="0.37889999" + id="stop9949" /> + <stop + style="stop-color:#b21714;stop-opacity:1" + offset="0.77649999" + id="stop9951" /> + <stop + style="stop-color:#a6100c;stop-opacity:1" + offset="1" + id="stop9953" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0.4213" /> + <a:midPointStop + style="stop-color:#A6100C" + offset="1" /> + </linearGradient> + <clipPath + id="XMLID_2273_"> + <use + id="use9933" + x="0" + y="0" + width="744.09448" + height="600" + xlink:href="#XMLID_960_" /> + </clipPath> + <linearGradient + x1="473.7681" + y1="209.17529" + x2="486.98099" + y2="213.2001" + id="XMLID_2274_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#f3403f;stop-opacity:1" + offset="0" + id="stop9936" /> + <stop + style="stop-color:#d02a28;stop-opacity:1" + offset="0.37889999" + id="stop9938" /> + <stop + style="stop-color:#b21714;stop-opacity:1" + offset="0.77649999" + id="stop9940" /> + <stop + style="stop-color:#a6100c;stop-opacity:1" + offset="1" + id="stop9942" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0.4213" /> + <a:midPointStop + style="stop-color:#A6100C" + offset="1" /> + </linearGradient> + <linearGradient + x1="478.21341" + y1="-131.9297" + x2="469.85818" + y2="-140.28481" + id="XMLID_2272_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.5592,0.829,-0.829,0.5592,101.3357,-104.791)"> + <stop + style="stop-color:#f3403f;stop-opacity:1" + offset="0" + id="stop9917" /> + <stop + style="stop-color:#d02a28;stop-opacity:1" + offset="0.37889999" + id="stop9919" /> + <stop + style="stop-color:#b21714;stop-opacity:1" + offset="0.77649999" + id="stop9921" /> + <stop + style="stop-color:#a6100c;stop-opacity:1" + offset="1" + id="stop9923" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0.4213" /> + <a:midPointStop + style="stop-color:#A6100C" + offset="1" /> + </linearGradient> + <marker + refX="0" + refY="0" + orient="auto" + style="overflow:visible" + id="TriangleInM"> + <path + d="M 5.77,0 L -2.88,5 L -2.88,-5 L 5.77,0 z " + transform="scale(-0.4,-0.4)" + style="fill:#5c5c4f" + id="path3197" /> + </marker> + <linearGradient + x1="200.7363" + y1="100.4028" + x2="211.99519" + y2="89.143997" + id="XMLID_3298_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#bfbfbf;stop-opacity:1" + offset="0" + id="stop20103" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="1" + id="stop20105" /> + <a:midPointStop + offset="0" + style="stop-color:#BFBFBF" /> + <a:midPointStop + offset="0.5" + style="stop-color:#BFBFBF" /> + <a:midPointStop + offset="1" + style="stop-color:#F2F2F2" /> + </linearGradient> + <linearGradient + x1="200.7363" + y1="100.4028" + x2="211.99519" + y2="89.143997" + id="linearGradient36592" + xlink:href="#XMLID_3298_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.029078,0,0,1,-183.2624,-79.44655)" /> + <linearGradient + x1="181.2925" + y1="110.8481" + x2="192.6369" + y2="99.5037" + id="XMLID_3297_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0" + id="stop20096" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="stop20098" /> + <a:midPointStop + offset="0" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="1" + style="stop-color:#CCCCCC" /> + </linearGradient> + <linearGradient + x1="181.2925" + y1="110.8481" + x2="192.6369" + y2="99.5037" + id="linearGradient36595" + xlink:href="#XMLID_3297_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.029078,0,0,1,-183.2624,-79.44655)" /> + <linearGradient + x1="211.77589" + y1="105.7749" + x2="212.6619" + y2="108.2092" + id="XMLID_3296_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#0f6124;stop-opacity:1" + offset="0" + id="stop20087" /> + <stop + style="stop-color:#219630;stop-opacity:1" + offset="1" + id="stop20089" /> + <a:midPointStop + offset="0" + style="stop-color:#0F6124" /> + <a:midPointStop + offset="0.5" + style="stop-color:#0F6124" /> + <a:midPointStop + offset="1" + style="stop-color:#219630" /> + </linearGradient> + <linearGradient + x1="211.77589" + y1="105.7749" + x2="212.6619" + y2="108.2092" + id="linearGradient36677" + xlink:href="#XMLID_3296_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.029078,0,0,1,-183.2624,-79.44655)" /> + <linearGradient + x1="208.9834" + y1="116.8296" + x2="200.0811" + y2="96.834602" + id="XMLID_3295_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0" + id="stop20076" /> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0.5" + id="stop20078" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="1" + id="stop20080" /> + <a:midPointStop + offset="0" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="1" + style="stop-color:#FFFFFF" /> + </linearGradient> + <linearGradient + x1="208.9834" + y1="116.8296" + x2="200.0811" + y2="96.834602" + id="linearGradient36604" + xlink:href="#XMLID_3295_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.029078,0,0,1,-183.2624,-79.44655)" /> + <linearGradient + x1="195.5264" + y1="97.911102" + x2="213.5213" + y2="115.9061" + id="XMLID_3294_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="0" + id="stop20069" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="1" + id="stop20071" /> + <a:midPointStop + offset="0" + style="stop-color:#CCCCCC" /> + <a:midPointStop + offset="0.5" + style="stop-color:#CCCCCC" /> + <a:midPointStop + offset="1" + style="stop-color:#FFFFFF" /> + </linearGradient> + <linearGradient + x1="195.5264" + y1="97.911102" + x2="213.5213" + y2="115.9061" + id="linearGradient36607" + xlink:href="#XMLID_3294_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.029078,0,0,1,-183.2624,-79.44655)" /> + <linearGradient + x1="186.1938" + y1="109.1343" + x2="206.6881" + y2="88.639999" + id="XMLID_3293_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0" + id="stop20056" /> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0.16850001" + id="stop20058" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="0.23029999" + id="stop20060" /> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0.2809" + id="stop20062" /> + <stop + style="stop-color:#c2c2c2;stop-opacity:1" + offset="0.5" + id="stop20064" /> + <a:midPointStop + offset="0" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="0.1685" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.2303" + style="stop-color:#FFFFFF" /> + <a:midPointStop + offset="0.5" + style="stop-color:#FFFFFF" /> + <a:midPointStop + offset="0.2809" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#C2C2C2" /> + </linearGradient> + <linearGradient + x1="186.1938" + y1="109.1343" + x2="206.6881" + y2="88.639999" + id="linearGradient36610" + xlink:href="#XMLID_3293_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.029078,0,0,1,-183.2624,-79.44655)" /> + <linearGradient + x1="184.8569" + y1="112.2676" + x2="211.94099" + y2="89.541397" + id="XMLID_3292_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0" + id="stop20043" /> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0.16850001" + id="stop20045" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="0.23029999" + id="stop20047" /> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0.2809" + id="stop20049" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="stop20051" /> + <a:midPointStop + offset="0" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="0.1685" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.2303" + style="stop-color:#FFFFFF" /> + <a:midPointStop + offset="0.5" + style="stop-color:#FFFFFF" /> + <a:midPointStop + offset="0.2809" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="1" + style="stop-color:#CCCCCC" /> + </linearGradient> + <linearGradient + x1="184.8569" + y1="112.2676" + x2="211.94099" + y2="89.541397" + id="linearGradient36613" + xlink:href="#XMLID_3292_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.029078,0,0,1,-183.2624,-79.44655)" /> + <marker + refX="0" + refY="0" + orient="auto" + style="overflow:visible" + id="TriangleOutM"> + <path + d="M 5.77,0 L -2.88,5 L -2.88,-5 L 5.77,0 z " + transform="scale(0.4,0.4)" + style="fill:#5c5c4f;fill-rule:evenodd;stroke-width:1pt;marker-start:none" + id="path3238" /> + </marker> + <linearGradient + x1="165.3" + y1="99.5" + x2="165.3" + y2="115.9" + id="XMLID_3457_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#999;stop-opacity:1" + offset="0" + id="stop8309" /> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0.30000001" + id="stop8311" /> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="1" + id="stop8313" /> + <a:midPointstop + offset="0" + style="stop-color:#999999" /> + <a:midPointstop + offset="0.5" + style="stop-color:#999999" /> + <a:midPointstop + offset="0.3" + style="stop-color:#B2B2B2" /> + <a:midPointstop + offset="0.5" + style="stop-color:#B2B2B2" /> + <a:midPointstop + offset="1" + style="stop-color:#B2B2B2" /> + </linearGradient> + <linearGradient + x1="165.3" + y1="99.5" + x2="165.3" + y2="115.9" + id="lg1997" + xlink:href="#XMLID_3457_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <linearGradient + x1="175" + y1="99.800003" + x2="175" + y2="112.5" + id="XMLID_3456_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#737373;stop-opacity:1" + offset="0" + id="stop8300" /> + <stop + style="stop-color:#191919;stop-opacity:1" + offset="0.60000002" + id="stop8302" /> + <stop + style="stop-color:#191919;stop-opacity:1" + offset="1" + id="stop8304" /> + <a:midPointstop + offset="0" + style="stop-color:#737373" /> + <a:midPointstop + offset="0.5" + style="stop-color:#737373" /> + <a:midPointstop + offset="0.6" + style="stop-color:#191919" /> + <a:midPointstop + offset="0.5" + style="stop-color:#191919" /> + <a:midPointstop + offset="1" + style="stop-color:#191919" /> + </linearGradient> + <linearGradient + x1="175" + y1="99.800003" + x2="175" + y2="112.5" + id="lg2000" + xlink:href="#XMLID_3456_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <linearGradient + x1="168.8" + y1="107.1" + x2="164.5" + y2="110" + id="XMLID_3455_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#666;stop-opacity:1" + offset="0" + id="stop8291" /> + <stop + style="stop-color:#191919;stop-opacity:1" + offset="0.69999999" + id="stop8293" /> + <stop + style="stop-color:#191919;stop-opacity:1" + offset="1" + id="stop8295" /> + <a:midPointstop + offset="0" + style="stop-color:#666666" /> + <a:midPointstop + offset="0.5" + style="stop-color:#666666" /> + <a:midPointstop + offset="0.7" + style="stop-color:#191919" /> + <a:midPointstop + offset="0.5" + style="stop-color:#191919" /> + <a:midPointstop + offset="1" + style="stop-color:#191919" /> + </linearGradient> + <linearGradient + x1="168.8" + y1="107.1" + x2="164.5" + y2="110" + id="lg2003" + xlink:href="#XMLID_3455_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <linearGradient + id="lg63694"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="stop63696" /> + <stop + style="stop-color:white;stop-opacity:0" + offset="1" + id="stop63698" /> + </linearGradient> + <linearGradient + x1="458" + y1="483" + x2="465.20001" + y2="271.39999" + id="lg2006" + xlink:href="#lg63694" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(6.3e-2,0,0,6.3e-2,-1.3,-9.8)" /> + <linearGradient + x1="176.3" + y1="110.1" + x2="158.7" + y2="105" + id="XMLID_3453_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#666;stop-opacity:1" + offset="0" + id="stop8271" /> + <stop + style="stop-color:#737373;stop-opacity:1" + offset="0.2" + id="stop8273" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="1" + id="stop8275" /> + <a:midPointstop + offset="0" + style="stop-color:#666666" /> + <a:midPointstop + offset="0.5" + style="stop-color:#666666" /> + <a:midPointstop + offset="0.2" + style="stop-color:#737373" /> + <a:midPointstop + offset="0.5" + style="stop-color:#737373" /> + <a:midPointstop + offset="1" + style="stop-color:#FFFFFF" /> + </linearGradient> + <linearGradient + x1="176.3" + y1="110.1" + x2="158.7" + y2="105" + id="lg2009" + xlink:href="#XMLID_3453_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <linearGradient + x1="173.60001" + y1="118.9" + x2="172.8" + y2="128.2" + id="XMLID_3449_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#ecb300;stop-opacity:1" + offset="0" + id="stop8232" /> + <stop + style="stop-color:#fff95e;stop-opacity:1" + offset="0.60000002" + id="stop8234" /> + <stop + style="stop-color:#ecd600;stop-opacity:1" + offset="1" + id="stop8236" /> + <a:midPointstop + offset="0" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.5" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.6" + style="stop-color:#FFF95E" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFF95E" /> + <a:midPointstop + offset="1" + style="stop-color:#ECD600" /> + </linearGradient> + <linearGradient + x1="173.60001" + y1="118.9" + x2="172.8" + y2="128.2" + id="lg2016" + xlink:href="#XMLID_3449_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <radialGradient + cx="284.60001" + cy="172.60001" + r="6.5" + fx="284.60001" + fy="172.60001" + id="XMLID_3448_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.4,0,0,1.4,-237.3,-126.8)"> + <stop + style="stop-color:#ecb300;stop-opacity:1" + offset="0" + id="stop8219" /> + <stop + style="stop-color:#ecb300;stop-opacity:1" + offset="0.30000001" + id="stop8221" /> + <stop + style="stop-color:#c96b00;stop-opacity:1" + offset="0.89999998" + id="stop8223" /> + <stop + style="stop-color:#9a5500;stop-opacity:1" + offset="1" + id="stop8225" /> + <a:midPointstop + offset="0" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.5" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.3" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.5" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.9" + style="stop-color:#C96B00" /> + <a:midPointstop + offset="0.5" + style="stop-color:#C96B00" /> + <a:midPointstop + offset="1" + style="stop-color:#9A5500" /> + </radialGradient> + <radialGradient + cx="284.60001" + cy="172.60001" + r="6.5" + fx="284.60001" + fy="172.60001" + id="rg2020" + xlink:href="#XMLID_3448_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.513992,0,0,2.347576,-689.1621,-378.5717)" /> + <linearGradient + x1="158.10001" + y1="123" + x2="164.2" + y2="126.6" + id="XMLID_3447_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#ecd600;stop-opacity:1" + offset="0" + id="stop8204" /> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="0.30000001" + id="stop8206" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="1" + id="stop8208" /> + <a:midPointstop + offset="0" + style="stop-color:#ECD600" /> + <a:midPointstop + offset="0.5" + style="stop-color:#ECD600" /> + <a:midPointstop + offset="0.3" + style="stop-color:#FFFFB3" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFFFB3" /> + <a:midPointstop + offset="1" + style="stop-color:#FFFFFF" /> + </linearGradient> + <linearGradient + x1="158.10001" + y1="123" + x2="164.2" + y2="126.6" + id="lg2026" + xlink:href="#XMLID_3447_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <radialGradient + cx="280.89999" + cy="163.7" + r="10.1" + fx="280.89999" + fy="163.7" + id="XMLID_3446_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.4,0,0,1.4,-237.3,-126.8)"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="stop8197" /> + <stop + style="stop-color:#fff95e;stop-opacity:1" + offset="1" + id="stop8199" /> + <a:midPointstop + offset="0" + style="stop-color:#FFFFFF" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFFFFF" /> + <a:midPointstop + offset="1" + style="stop-color:#FFF95E" /> + </radialGradient> + <radialGradient + cx="280.89999" + cy="163.7" + r="10.1" + fx="280.89999" + fy="163.7" + id="rg2029" + xlink:href="#XMLID_3446_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.7,0,0,1.7,-457.5,-266.8)" /> + <linearGradient + x1="156.5" + y1="122.7" + x2="180.10001" + y2="122.7" + id="XMLID_3445_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#ecb300;stop-opacity:1" + offset="0" + id="stop8184" /> + <stop + style="stop-color:#ffe900;stop-opacity:1" + offset="0.2" + id="stop8186" /> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="0.30000001" + id="stop8188" /> + <stop + style="stop-color:#ffe900;stop-opacity:1" + offset="0.40000001" + id="stop8190" /> + <stop + style="stop-color:#d68100;stop-opacity:1" + offset="1" + id="stop8192" /> + <a:midPointstop + offset="0" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.5" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.2" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="0.3" + style="stop-color:#FFFFB3" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFFFB3" /> + <a:midPointstop + offset="0.4" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="1" + style="stop-color:#D68100" /> + </linearGradient> + <linearGradient + x1="156.5" + y1="122.7" + x2="180.10001" + y2="122.7" + id="lg2032" + xlink:href="#XMLID_3445_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <linearGradient + x1="156.39999" + y1="115.4" + x2="180.10001" + y2="115.4" + id="XMLID_3444_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#ecb300;stop-opacity:1" + offset="0" + id="stop8171" /> + <stop + style="stop-color:#ffe900;stop-opacity:1" + offset="0.2" + id="stop8173" /> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="0.30000001" + id="stop8175" /> + <stop + style="stop-color:#ffe900;stop-opacity:1" + offset="0.40000001" + id="stop8177" /> + <stop + style="stop-color:#d68100;stop-opacity:1" + offset="1" + id="stop8179" /> + <a:midPointstop + offset="0" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.5" + style="stop-color:#ECB300" /> + <a:midPointstop + offset="0.2" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="0.3" + style="stop-color:#FFFFB3" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFFFB3" /> + <a:midPointstop + offset="0.4" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="0.5" + style="stop-color:#FFE900" /> + <a:midPointstop + offset="1" + style="stop-color:#D68100" /> + </linearGradient> + <linearGradient + x1="156.39999" + y1="115.4" + x2="180.10001" + y2="115.4" + id="lg2035" + xlink:href="#XMLID_3444_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.2,0,0,1.2,-175.9,-114.6)" /> + <linearGradient + x1="379.70001" + y1="167.89999" + x2="383.89999" + y2="172.89999" + id="lg4286_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.8,0.2,-0.2,0.8,78.8,38.1)"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="s16159" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="0.1" + id="s16161" /> + <stop + style="stop-color:#737373;stop-opacity:1" + offset="1" + id="s16163" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.1" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#737373" + offset="1" /> + </linearGradient> + <linearGradient + x1="379.60001" + y1="167.8" + x2="383.79999" + y2="172" + id="lg6416" + xlink:href="#lg4286_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.622156,0.623859,-0.623859,2.62182,-882.9706,-673.7921)" /> + <linearGradient + x1="384.20001" + y1="169.8" + x2="384.79999" + y2="170.39999" + id="lg4285_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.8,0.2,-0.2,0.8,78.8,38.1)"> + <stop + style="stop-color:#737373;stop-opacity:1" + offset="0" + id="s16152" /> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="1" + id="s16154" /> + <ns:midPointStop + style="stop-color:#737373" + offset="0" /> + <ns:midPointStop + style="stop-color:#737373" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#D9D9D9" + offset="1" /> + </linearGradient> + <linearGradient + x1="384.20001" + y1="169.8" + x2="384.79999" + y2="170.39999" + id="lg6453" + xlink:href="#lg4285_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.6,0.6,-0.6,2.6,-883,-673.8)" /> + <linearGradient + x1="380.5" + y1="172.60001" + x2="382.79999" + y2="173.7" + id="lg4284_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.8,0.2,-0.2,0.8,78.8,38.1)"> + <stop + style="stop-color:gray;stop-opacity:1" + offset="0" + id="s16145" /> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="1" + id="s16147" /> + <ns:midPointStop + style="stop-color:#808080" + offset="0" /> + <ns:midPointStop + style="stop-color:#808080" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#E5E5E5" + offset="1" /> + </linearGradient> + <linearGradient + x1="380.5" + y1="172.60001" + x2="382.79999" + y2="173.7" + id="lg6456" + xlink:href="#lg4284_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.6,0.6,-0.6,2.6,-883,-673.8)" /> + <radialGradient + cx="347.29999" + cy="244.5" + r="5.1999998" + fx="347.29999" + fy="244.5" + id="lg4282_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(3.4,0,0,3.4,-1148,-802)"> + <stop + style="stop-color:#333;stop-opacity:1" + offset="0" + id="s16135" /> + <stop + style="stop-color:#999;stop-opacity:1" + offset="1" + id="s16137" /> + <ns:midPointStop + style="stop-color:#333333" + offset="0" /> + <ns:midPointStop + style="stop-color:#333333" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#999999" + offset="1" /> + </radialGradient> + <linearGradient + x1="310.39999" + y1="397.70001" + x2="310.89999" + y2="399.5" + id="lg4280_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.7,-0.7,0.7,0.7,-153.4,180.6)"> + <stop + style="stop-color:#ffcd00;stop-opacity:1" + offset="0" + id="s16111" /> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="0.60000002" + id="s16113" /> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="1" + id="s16115" /> + <ns:midPointStop + style="stop-color:#FFCD00" + offset="0" /> + <ns:midPointStop + style="stop-color:#FFCD00" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0.6" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="1" /> + </linearGradient> + <linearGradient + x1="310.39999" + y1="397.70001" + x2="310.89999" + y2="399.5" + id="lg6467" + xlink:href="#lg4280_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.4,-2.4,2.4,2.4,-1663.6,-195)" /> + <linearGradient + x1="310.89999" + y1="395.79999" + x2="313.29999" + y2="403.10001" + id="lg4279_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.7,-0.7,0.7,0.7,-153.4,180.6)"> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="0" + id="s16100" /> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="0.40000001" + id="s16102" /> + <stop + style="stop-color:#ffcd00;stop-opacity:1" + offset="0.89999998" + id="s16104" /> + <stop + style="stop-color:#ffcd00;stop-opacity:1" + offset="1" + id="s16106" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0.4" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFCD00" + offset="0.9" /> + <ns:midPointStop + style="stop-color:#FFCD00" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFCD00" + offset="1" /> + </linearGradient> + <linearGradient + x1="310.89999" + y1="395.79999" + x2="313.29999" + y2="403.10001" + id="lg6465" + xlink:href="#lg4279_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.4,-2.4,2.4,2.4,-1663.6,-195)" /> + <linearGradient + x1="307.79999" + y1="395.20001" + x2="313.79999" + y2="413.60001" + id="lg4278_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.7,-0.7,0.7,0.7,-153.4,180.6)"> + <stop + style="stop-color:#ffffb3;stop-opacity:1" + offset="0" + id="s16091" /> + <stop + style="stop-color:#fcd72f;stop-opacity:1" + offset="0.40000001" + id="s16093" /> + <stop + style="stop-color:#ffcd00;stop-opacity:1" + offset="1" + id="s16095" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0" /> + <ns:midPointStop + style="stop-color:#FFFFB3" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FCD72F" + offset="0.4" /> + <ns:midPointStop + style="stop-color:#FCD72F" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFCD00" + offset="1" /> + </linearGradient> + <linearGradient + x1="306.5" + y1="393" + x2="309" + y2="404" + id="lg6400" + xlink:href="#lg4278_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.4,-2.4,2.4,2.4,-1663.6,-195)" /> + <linearGradient + x1="352.10001" + y1="253.60001" + x2="348.5" + y2="237.8" + id="lg4276_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(3.4,0,0,3.4,-1148,-802)"> + <stop + style="stop-color:#ffff87;stop-opacity:1" + offset="0" + id="s16077" /> + <stop + style="stop-color:#ffad00;stop-opacity:1" + offset="1" + id="s16079" /> + <ns:midPointStop + style="stop-color:#FFFF87" + offset="0" /> + <ns:midPointStop + style="stop-color:#FFFF87" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFAD00" + offset="1" /> + </linearGradient> + <linearGradient + x1="335.60001" + y1="354.79999" + x2="337.89999" + y2="354.79999" + id="lg4275_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9,-0.5,0.5,0.9,-121.7,105.1)"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="s16057" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="0.80000001" + id="s16059" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="1" + id="s16061" /> + <ns:midPointStop + style="stop-color:#D9D9D9" + offset="0" /> + <ns:midPointStop + style="stop-color:#D9D9D9" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.8" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="1" /> + </linearGradient> + <linearGradient + x1="335.60001" + y1="354.79999" + x2="337.89999" + y2="354.79999" + id="lg6463" + xlink:href="#lg4275_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.9,-1.7,1.7,2.9,-1557,-448.7)" /> + <linearGradient + x1="337.39999" + y1="353.10001" + x2="339.39999" + y2="357.10001" + id="lg4274_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9,-0.5,0.5,0.9,-121.7,105.1)"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="s16048" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="0.1" + id="s16050" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="s16052" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.1" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#CCCCCC" + offset="1" /> + </linearGradient> + <linearGradient + x1="337.39999" + y1="353.10001" + x2="339.39999" + y2="357.10001" + id="lg6461" + xlink:href="#lg4274_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.9,-1.7,1.7,2.9,-1557,-448.7)" /> + <linearGradient + x1="334.39999" + y1="355.5" + x2="335.5" + y2="356.79999" + id="lg4273_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9,-0.5,0.5,0.9,-121.7,105.1)"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="s16041" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="s16043" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="5.6e-003" /> + <ns:midPointStop + style="stop-color:#FFFFFF" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#CCCCCC" + offset="1" /> + </linearGradient> + <linearGradient + x1="334.39999" + y1="355.5" + x2="335.5" + y2="356.79999" + id="lg6381" + xlink:href="#lg4273_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(2.9,-1.7,1.7,2.9,-1557,-448.7)" /> + <linearGradient + x1="348.39999" + y1="247.39999" + x2="354.10001" + y2="242" + id="lg4271_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(3.4,0,0,3.4,-1148,-802)"> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="0" + id="s16025" /> + <stop + style="stop-color:#9e9e9e;stop-opacity:1" + offset="0.40000001" + id="s16027" /> + <stop + style="stop-color:black;stop-opacity:1" + offset="1" + id="s16029" /> + <ns:midPointStop + style="stop-color:#F2F2F2" + offset="0" /> + <ns:midPointStop + style="stop-color:#F2F2F2" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#000000" + offset="1" /> + </linearGradient> + <linearGradient + x1="351.29999" + y1="257.29999" + x2="346.29999" + y2="235.5" + id="lg4270_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#ffff87;stop-opacity:1" + offset="0" + id="s16007" /> + <stop + style="stop-color:#ffad00;stop-opacity:1" + offset="1" + id="s16009" /> + <ns:midPointStop + style="stop-color:#FFFF87" + offset="0" /> + <ns:midPointStop + style="stop-color:#FFFF87" + offset="0.5" /> + <ns:midPointStop + style="stop-color:#FFAD00" + offset="1" /> + </linearGradient> + <linearGradient + x1="351.29999" + y1="257.29999" + x2="346.29999" + y2="235.5" + id="lg6459" + xlink:href="#lg4270_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(3.4,0,0,3.4,-1148,-802)" /> + <linearGradient + x1="43.799999" + y1="32.5" + x2="63.299999" + y2="66.400002" + id="XMLID_2708_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="stop75318" /> + <stop + style="stop-color:#fffcea;stop-opacity:1" + offset="1" + id="stop75320" /> + <a:midPointStop + style="stop-color:#FFFFFF" + offset="0" /> + <a:midPointStop + style="stop-color:#FFFFFF" + offset="0.5" /> + <a:midPointStop + style="stop-color:#FFFCEA" + offset="1" /> + </linearGradient> + <linearGradient + x1="43.799999" + y1="32.5" + x2="63.299999" + y2="66.400002" + id="lg1907" + xlink:href="#XMLID_2708_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(-29,-22.6)" /> + <linearGradient + x1="52.5" + y1="40.400002" + x2="58.200001" + y2="64" + id="XMLID_2707_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#ffdea0;stop-opacity:1" + offset="0" + id="stop75305" /> + <stop + style="stop-color:#ffd89e;stop-opacity:1" + offset="0.30000001" + id="stop75307" /> + <stop + style="stop-color:#ffd79e;stop-opacity:1" + offset="0.30000001" + id="stop75309" /> + <stop + style="stop-color:#dbaf6d;stop-opacity:1" + offset="0.69999999" + id="stop75311" /> + <stop + style="stop-color:#6f4c24;stop-opacity:1" + offset="1" + id="stop75313" /> + <a:midPointStop + style="stop-color:#FFDEA0" + offset="0" /> + <a:midPointStop + style="stop-color:#FFDEA0" + offset="0.6" /> + <a:midPointStop + style="stop-color:#FFD79E" + offset="0.3" /> + <a:midPointStop + style="stop-color:#FFD79E" + offset="0.5" /> + <a:midPointStop + style="stop-color:#DBAF6D" + offset="0.7" /> + <a:midPointStop + style="stop-color:#DBAF6D" + offset="0.5" /> + <a:midPointStop + style="stop-color:#6F4C24" + offset="1" /> + </linearGradient> + <linearGradient + x1="52.5" + y1="40.400002" + x2="58.200001" + y2="64" + id="lg1910" + xlink:href="#XMLID_2707_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(-29,-22.6)" /> + <linearGradient + x1="58" + y1="73.199997" + x2="44.5" + y2="19" + id="XMLID_2704_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(-29,-22.6)"> + <stop + style="stop-color:#d4a96c;stop-opacity:1" + offset="0.5" + id="stop75284" /> + <stop + style="stop-color:#dcb273;stop-opacity:1" + offset="0.60000002" + id="stop75286" /> + <stop + style="stop-color:#f0ca87;stop-opacity:1" + offset="0.80000001" + id="stop75288" /> + <stop + style="stop-color:#ffdc96;stop-opacity:1" + offset="0.69999999" + id="stop75290" /> + <stop + style="stop-color:#c18a42;stop-opacity:1" + offset="1" + id="stop75292" /> + <a:midPointStop + style="stop-color:#D4A96C" + offset="0.5" /> + <a:midPointStop + style="stop-color:#D4A96C" + offset="0.6" /> + <a:midPointStop + style="stop-color:#FFDC96" + offset="0.7" /> + <a:midPointStop + style="stop-color:#FFDC96" + offset="0.5" /> + <a:midPointStop + style="stop-color:#C18A42" + offset="1" /> + </linearGradient> + <linearGradient + x1="53.700001" + y1="32" + x2="53.700001" + y2="64.599998" + id="XMLID_2703_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#e5c9b0;stop-opacity:1" + offset="0" + id="stop75268" /> + <stop + style="stop-color:#e5c9b0;stop-opacity:1" + offset="0.40000001" + id="stop75270" /> + <stop + style="stop-color:#c0aa94;stop-opacity:1" + offset="1" + id="stop75272" /> + <a:midPointStop + style="stop-color:#E5C9B0" + offset="0" /> + <a:midPointStop + style="stop-color:#E5C9B0" + offset="0.5" /> + <a:midPointStop + style="stop-color:#E5C9B0" + offset="0.4" /> + <a:midPointStop + style="stop-color:#E5C9B0" + offset="0.5" /> + <a:midPointStop + style="stop-color:#C0AA94" + offset="1" /> + </linearGradient> + <linearGradient + x1="53.700001" + y1="32" + x2="53.700001" + y2="64.599998" + id="lg1916" + xlink:href="#XMLID_2703_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(-29,-22.6)" /> + <linearGradient + x1="224.31" + y1="19.450001" + x2="214.33" + y2="11.46" + id="XMLID_419_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#404040;stop-opacity:1" + offset="0" + id="s1903" /> + <stop + style="stop-color:#6d6d6d;stop-opacity:1" + offset="0.33000001" + id="s1905" /> + <stop + style="stop-color:#e9e9e9;stop-opacity:1" + offset="1" + id="s1907" /> + <a:midPointStop + offset="0" + style="stop-color:#404040" /> + <a:midPointStop + offset="0.5" + style="stop-color:#404040" /> + <a:midPointStop + offset="0.33" + style="stop-color:#6D6D6D" /> + <a:midPointStop + offset="0.5" + style="stop-color:#6D6D6D" /> + <a:midPointStop + offset="1" + style="stop-color:#E9E9E9" /> + </linearGradient> + <linearGradient + x1="221.84" + y1="32.779999" + x2="212.2" + y2="20.27" + id="lg1988" + xlink:href="#XMLID_419_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.33,0,0,1.31,-274.2,-5.2)" /> + <linearGradient + x1="228.35001" + y1="33.279999" + x2="215.42999" + y2="33.279999" + id="lg1900" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="s1902" /> + <stop + style="stop-color:white;stop-opacity:0" + offset="1" + id="s1906" /> + <a:midPointStop + style="stop-color:#575757" + offset="0" /> + <a:midPointStop + style="stop-color:#575757" + offset="0.5" /> + <a:midPointStop + style="stop-color:#6D6D6D" + offset="0.33" /> + <a:midPointStop + style="stop-color:#6D6D6D" + offset="0.5" /> + <a:midPointStop + style="stop-color:#D3D3D3" + offset="1" /> + </linearGradient> + <linearGradient + x1="234.81" + y1="33.279999" + x2="228.27" + y2="33.279999" + id="lg1908" + xlink:href="#lg1900" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.33,0,0,1.31,-274.2,-5.2)" /> + <linearGradient + x1="228.35001" + y1="33.279999" + x2="215.42999" + y2="33.279999" + id="XMLID_416_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#575757;stop-opacity:1" + offset="0" + id="s1874" /> + <stop + style="stop-color:#6d6d6d;stop-opacity:1" + offset="0.33000001" + id="s1876" /> + <stop + style="stop-color:#d3d3d3;stop-opacity:1" + offset="1" + id="s1878" /> + <a:midPointStop + offset="0" + style="stop-color:#575757" /> + <a:midPointStop + offset="0.5" + style="stop-color:#575757" /> + <a:midPointStop + offset="0.33" + style="stop-color:#6D6D6D" /> + <a:midPointStop + offset="0.5" + style="stop-color:#6D6D6D" /> + <a:midPointStop + offset="1" + style="stop-color:#D3D3D3" /> + </linearGradient> + <linearGradient + x1="228.35001" + y1="33.279999" + x2="215.42999" + y2="33.279999" + id="lg1991" + xlink:href="#XMLID_416_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.33,0,0,1.31,-274.2,-5.2)" /> + <radialGradient + cx="603.19" + cy="230.77" + r="1.67" + fx="603.19" + fy="230.77" + id="x5010_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.1,0,0,1.1,-54.33,-75.4)"> + <stop + style="stop-color:#c9ffc9;stop-opacity:1" + offset="0" + id="stop29201" /> + <stop + style="stop-color:#23a11f;stop-opacity:1" + offset="1" + id="stop29203" /> + <a:midPointStop + offset="0" + style="stop-color:#C9FFC9" /> + <a:midPointStop + offset="0.5" + style="stop-color:#C9FFC9" /> + <a:midPointStop + offset="1" + style="stop-color:#23A11F" /> + </radialGradient> + <radialGradient + cx="603.19" + cy="230.77" + r="1.67" + fx="603.19" + fy="230.77" + id="radialGradient5711" + xlink:href="#x5010_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.23,0,0,1.23,-709.93,-245.02)" /> + <linearGradient + x1="592.31" + y1="162.60001" + x2="609.32001" + y2="145.59" + id="lg5722" + xlink:href="#x5003_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.12,0,0,1.12,-649.08,-160.62)" /> + <linearGradient + x1="601.48999" + y1="170.16" + x2="613.84003" + y2="170.16" + id="x5002_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="stop29134" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="0.2" + id="stop29136" /> + <stop + style="stop-color:#999;stop-opacity:1" + offset="1" + id="stop29138" /> + <a:midPointStop + offset="0" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.5" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.20" + style="stop-color:#FFFFFF" /> + <a:midPointStop + offset="0.5" + style="stop-color:#FFFFFF" /> + <a:midPointStop + offset="1" + style="stop-color:#999999" /> + </linearGradient> + <linearGradient + x1="601.48999" + y1="170.16" + x2="613.84003" + y2="170.16" + id="lg5725" + xlink:href="#x5002_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.12,0,0,1.12,-649.08,-160.62)" /> + <linearGradient + x1="592.20001" + y1="156.45" + x2="609.98999" + y2="174.23" + id="x5004_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.12,0,0,1.12,-649.08,-160.62)"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="stop29157" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="1" + id="stop29159" /> + <a:midPointStop + offset="0" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.5" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="1" + style="stop-color:#FFFFFF" /> + </linearGradient> + <linearGradient + x1="592.20001" + y1="156.45" + x2="609.98999" + y2="174.23" + id="lg5728" + xlink:href="#x5004_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.12,0,0,1.12,-649.08,-160.62)" /> + <linearGradient + x1="592.31" + y1="162.60001" + x2="609.32001" + y2="145.59" + id="x5003_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="0" + id="stop29143" /> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="1" + id="stop29145" /> + <a:midPointStop + offset="0" + style="stop-color:#F2F2F2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#F2F2F2" /> + <a:midPointStop + offset="1" + style="stop-color:#E5E5E5" /> + </linearGradient> + <linearGradient + x1="592.31" + y1="162.60001" + x2="609.32001" + y2="145.59" + id="lg5732" + xlink:href="#x5003_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.12,0,0,1.12,-649.08,-160.62)" /> + <linearGradient + x1="592.20001" + y1="156.45" + x2="609.98999" + y2="174.24001" + id="x5000_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.12,0,0,1.12,-649.08,-160.62)"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="stop29124" /> + <stop + style="stop-color:white;stop-opacity:1" + offset="1" + id="stop29126" /> + <a:midPointStop + offset="0" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.5" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="1" + style="stop-color:#FFFFFF" /> + </linearGradient> + <linearGradient + x1="592.20001" + y1="156.45" + x2="609.98999" + y2="174.24001" + id="lg5735" + xlink:href="#x5000_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.12,0,0,1.12,-649.08,-160.62)" /> + <linearGradient + x1="308.54999" + y1="149.89999" + x2="299.72" + y2="148.83" + id="XMLID_2433_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#d6d6d6;stop-opacity:1" + offset="0" + id="71615" /> + <stop + style="stop-color:#a5a5a5;stop-opacity:1" + offset="1" + id="71617" /> + <a:midPointStop + offset="0" + style="stop-color:#D6D6D6" /> + <a:midPointStop + offset="0.5" + style="stop-color:#D6D6D6" /> + <a:midPointStop + offset="1" + style="stop-color:#A5A5A5" /> + </linearGradient> + <linearGradient + x1="308.54999" + y1="149.89999" + x2="299.72" + y2="148.83" + id="lg1952" + xlink:href="#XMLID_2433_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.03,0,0,1.03,-279.57,-124.36)" /> + <radialGradient + cx="307.39999" + cy="121" + r="23.35" + fx="307.39999" + fy="121" + id="XMLID_2432_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.98,0,0,0.98,2.88,2.75)"> + <stop + style="stop-color:#d2d2d2;stop-opacity:1" + offset="0.19" + id="71592" /> + <stop + style="stop-color:#cfcfcf;stop-opacity:1" + offset="0.44999999" + id="71594" /> + <stop + style="stop-color:#c7c7c7;stop-opacity:1" + offset="0.60000002" + id="71596" /> + <stop + style="stop-color:#b9b9b9;stop-opacity:1" + offset="0.74000001" + id="71598" /> + <stop + style="stop-color:#a4a4a4;stop-opacity:1" + offset="0.86000001" + id="71600" /> + <stop + style="stop-color:#8a8a8a;stop-opacity:1" + offset="0.95999998" + id="71602" /> + <stop + style="stop-color:gray;stop-opacity:1" + offset="1" + id="71604" /> + <a:midPointStop + offset="0.19" + style="stop-color:#D2D2D2" /> + <a:midPointStop + offset="0.8" + style="stop-color:#D2D2D2" /> + <a:midPointStop + offset="1" + style="stop-color:#808080" /> + </radialGradient> + <radialGradient + cx="307.39999" + cy="121" + r="23.35" + fx="307.39999" + fy="121" + id="radialGradient2331" + xlink:href="#XMLID_2432_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(-276.62,-121.54)" /> + <linearGradient + x1="294.13" + y1="127.07" + x2="294.13" + y2="142.2" + id="XMLID_2430_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#b5d8ff;stop-opacity:1" + offset="0" + id="71582" /> + <stop + style="stop-color:black;stop-opacity:1" + offset="1" + id="71584" /> + <a:midPointStop + offset="0" + style="stop-color:#B5D8FF" /> + <a:midPointStop + offset="0.5" + style="stop-color:#B5D8FF" /> + <a:midPointStop + offset="1" + style="stop-color:#000000" /> + </linearGradient> + <linearGradient + x1="294.13" + y1="127.07" + x2="294.13" + y2="142.2" + id="lg2820" + xlink:href="#XMLID_2430_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.03,0,0,1.03,-279.57,-124.36)" /> + <linearGradient + x1="279.10999" + y1="148.03" + x2="309.16" + y2="148.03" + id="XMLID_2429_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#e1e1e1;stop-opacity:1" + offset="0" + id="71564" /> + <stop + style="stop-color:#e1e1e1;stop-opacity:1" + offset="0.25" + id="71566" /> + <stop + style="stop-color:#a5a5a5;stop-opacity:1" + offset="0.44" + id="71568" /> + <stop + style="stop-color:#a5a5a5;stop-opacity:1" + offset="1" + id="71570" /> + <a:midPointStop + offset="0" + style="stop-color:#E1E1E1" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E1E1E1" /> + <a:midPointStop + offset="0.25" + style="stop-color:#E1E1E1" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E1E1E1" /> + <a:midPointStop + offset="0.44" + style="stop-color:#A5A5A5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#A5A5A5" /> + <a:midPointStop + offset="1" + style="stop-color:#A5A5A5" /> + </linearGradient> + <linearGradient + x1="279.10999" + y1="148.03" + x2="309.16" + y2="148.03" + id="lg2818" + xlink:href="#XMLID_2429_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.03,0,0,1.03,-279.57,-124.36)" /> + <radialGradient + cx="622.34302" + cy="14.449" + r="26.496" + fx="622.34302" + fy="14.449" + id="lg3499_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.851,0,0,0.849,69.297,51.658)"> + <stop + style="stop-color:#23468e;stop-opacity:1" + offset="0" + id="stop10972" /> + <stop + style="stop-color:#012859;stop-opacity:1" + offset="1" + id="stop10974" /> + <a:midPointStop + offset="0" + style="stop-color:#23468E" /> + <a:midPointStop + offset="0.5" + style="stop-color:#23468E" /> + <a:midPointStop + offset="1" + style="stop-color:#012859" /> + </radialGradient> + <radialGradient + cx="622.34302" + cy="14.449" + r="26.496" + fx="622.34302" + fy="14.449" + id="rg5791" + xlink:href="#lg3499_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.858,0,0,0.857,-511.7,9.02)" /> + <linearGradient + x1="616.112" + y1="76.247002" + x2="588.14099" + y2="60.742001" + id="lg3497_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#01326e;stop-opacity:1" + offset="0" + id="stop10962" /> + <stop + style="stop-color:#012859;stop-opacity:1" + offset="1" + id="stop10964" /> + <a:midPointStop + offset="0" + style="stop-color:#01326E" /> + <a:midPointStop + offset="0.5" + style="stop-color:#01326E" /> + <a:midPointStop + offset="1" + style="stop-color:#012859" /> + </linearGradient> + <linearGradient + x1="617.698" + y1="82.445999" + x2="585.95203" + y2="54.848999" + id="lg3496_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0" + id="stop10950" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="stop10952" /> + <a:midPointStop + offset="0" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="0.5" + style="stop-color:#E5E5E5" /> + <a:midPointStop + offset="1" + style="stop-color:#CCCCCC" /> + </linearGradient> + <linearGradient + x1="617.698" + y1="82.445999" + x2="585.95203" + y2="54.848999" + id="lg5794" + xlink:href="#lg3496_" + gradientUnits="userSpaceOnUse" /> + <linearGradient + x1="601.39001" + y1="55.341" + x2="588.29199" + y2="71.515999" + id="lg3495_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="stop10941" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="0.52200001" + id="stop10943" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="stop10945" /> + <a:midPointStop + offset="0" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.5" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.522" + style="stop-color:#F2F2F2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#F2F2F2" /> + <a:midPointStop + offset="1" + style="stop-color:#CCCCCC" /> + </linearGradient> + <linearGradient + x1="601.39001" + y1="55.341" + x2="588.29199" + y2="71.515999" + id="lg5771" + xlink:href="#lg3495_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.009,0,0,1.009,-581.615,-43.098)" /> + <linearGradient + x1="611.34601" + y1="55.279999" + x2="590.39001" + y2="81.157997" + id="lg3494_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="stop10932" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="0.52200001" + id="stop10934" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="stop10936" /> + <a:midPointStop + offset="0" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.5" + style="stop-color:#D9D9D9" /> + <a:midPointStop + offset="0.522" + style="stop-color:#F2F2F2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#F2F2F2" /> + <a:midPointStop + offset="1" + style="stop-color:#CCCCCC" /> + </linearGradient> + <linearGradient + x1="611.34601" + y1="55.279999" + x2="590.39001" + y2="81.157997" + id="lg5774" + xlink:href="#lg3494_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.009,0,0,1.009,-581.616,-43.098)" /> + <linearGradient + x1="798.72998" + y1="69.839996" + x2="799.04999" + y2="70.709999" + id="g3302_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#005e00;stop-opacity:1" + offset="0" + id="s6504" /> + <stop + style="stop-color:#23a11f;stop-opacity:1" + offset="1" + id="s6506" /> + <a:midPointstop + style="stop-color:#005E00" + offset="0" /> + <a:midPointstop + style="stop-color:#005E00" + offset="0.5" /> + <a:midPointstop + style="stop-color:#23A11F" + offset="1" /> + </linearGradient> + <linearGradient + x1="798.72998" + y1="69.839996" + x2="799.04999" + y2="70.709999" + id="lg5851" + xlink:href="#g3302_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.204,0,0,1.263,-926.036,-60.001)" /> + <linearGradient + x1="779.19" + y1="122.73" + x2="811.69" + y2="149.74001" + id="g3301_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1,-0.25,0,1,0,129.19)"> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="0" + id="s6483" /> + <stop + style="stop-color:#eee;stop-opacity:1" + offset="0.17" + id="s6485" /> + <stop + style="stop-color:#e3e3e3;stop-opacity:1" + offset="0.34" + id="s6487" /> + <stop + style="stop-color:#cfcfcf;stop-opacity:1" + offset="0.50999999" + id="s6489" /> + <stop + style="stop-color:#b4b4b4;stop-opacity:1" + offset="0.67000002" + id="s6491" /> + <stop + style="stop-color:#919191;stop-opacity:1" + offset="0.83999997" + id="s6493" /> + <stop + style="stop-color:#666;stop-opacity:1" + offset="1" + id="s6495" /> + <a:midPointstop + style="stop-color:#F2F2F2" + offset="0" /> + <a:midPointstop + style="stop-color:#F2F2F2" + offset="0.71" /> + <a:midPointstop + style="stop-color:#666666" + offset="1" /> + </linearGradient> + <linearGradient + x1="779.19" + y1="122.73" + x2="811.69" + y2="149.74001" + id="lg5855" + xlink:href="#g3301_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.204,-0.316,0,1.263,-926.036,103.123)" /> + <clipPath + id="g3299_"> + <use + id="use6469" + x="0" + y="0" + width="1005.92" + height="376.97" + xlink:href="#g101_" /> + </clipPath> + <radialGradient + cx="1189.9301" + cy="100.05" + r="40.400002" + fx="1189.9301" + fy="100.05" + id="g3300_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.34,-8.46e-2,0,0.34,394.16,137.13)"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="s6472" /> + <stop + style="stop-color:white;stop-opacity:0" + offset="1" + id="s6474" /> + <a:midPointstop + style="stop-color:#FFFFFF" + offset="0" /> + <a:midPointstop + style="stop-color:#FFFFFF" + offset="0.5" /> + <a:midPointstop + style="stop-color:#000000" + offset="1" /> + </radialGradient> + <radialGradient + cx="1199.74" + cy="97.150002" + r="40.400002" + fx="1199.74" + fy="97.150002" + id="rg5860" + xlink:href="#g3300_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.409,-0.107,0,0.429,-451.489,113.149)" /> + <linearGradient + x1="796.38" + y1="67.580002" + x2="781.28003" + y2="58.549999" + id="g3298_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#4c8bca;stop-opacity:1" + offset="0" + id="s6462" /> + <stop + style="stop-color:#b7e9ff;stop-opacity:1" + offset="1" + id="s6464" /> + <a:midPointstop + style="stop-color:#4C8BCA" + offset="0" /> + <a:midPointstop + style="stop-color:#4C8BCA" + offset="0.5" /> + <a:midPointstop + style="stop-color:#B7E9FF" + offset="1" /> + </linearGradient> + <linearGradient + x1="800.97998" + y1="140.72" + x2="777.71997" + y2="121.76" + id="g3297_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1,-0.25,0,1,0,129.19)"> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0" + id="s6448" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="s6450" /> + <a:midPointstop + style="stop-color:#E5E5E5" + offset="0" /> + <a:midPointstop + style="stop-color:#E5E5E5" + offset="0.5" /> + <a:midPointstop + style="stop-color:#CCCCCC" + offset="1" /> + </linearGradient> + <linearGradient + x1="800.97998" + y1="140.72" + x2="777.71997" + y2="121.76" + id="lg5890" + xlink:href="#g3297_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1,-0.25,0,1,0,129.19)" /> + <linearGradient + x1="790.03998" + y1="-16.33" + x2="779.84003" + y2="-3.73" + id="g3296_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(0,70.17)"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="s6439" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="0.51999998" + id="s6441" /> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="1" + id="s6443" /> + <a:midPointstop + style="stop-color:#D9D9D9" + offset="0" /> + <a:midPointstop + style="stop-color:#D9D9D9" + offset="0.5" /> + <a:midPointstop + style="stop-color:#F2F2F2" + offset="0.52" /> + <a:midPointstop + style="stop-color:#F2F2F2" + offset="0.5" /> + <a:midPointstop + style="stop-color:#CCCCCC" + offset="1" /> + </linearGradient> + <linearGradient + x1="790.03998" + y1="-16.33" + x2="779.84003" + y2="-3.73" + id="lg5866" + xlink:href="#g3296_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.204,0,0,1.263,-926.036,28.6)" /> + <linearGradient + x1="785.84003" + y1="72.989998" + x2="785.26001" + y2="76.279999" + id="g3293_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="s6412" /> + <stop + style="stop-color:#737373;stop-opacity:1" + offset="1" + id="s6414" /> + <a:midPointstop + style="stop-color:#FFFFFF" + offset="0" /> + <a:midPointstop + style="stop-color:#FFFFFF" + offset="0.5" /> + <a:midPointstop + style="stop-color:#737373" + offset="1" /> + </linearGradient> + <linearGradient + x1="785.84003" + y1="72.989998" + x2="785.26001" + y2="76.279999" + id="lg5871" + xlink:href="#g3293_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.204,0,0,1.263,-926.036,-60.001)" /> + <linearGradient + x1="789.37" + y1="69.879997" + x2="791.03998" + y2="77.120003" + id="g3292_" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#999;stop-opacity:1" + offset="0" + id="s6403" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="0.28" + id="s6405" /> + <stop + style="stop-color:#666;stop-opacity:1" + offset="1" + id="s6407" /> + <a:midPointstop + style="stop-color:#999999" + offset="0" /> + <a:midPointstop + style="stop-color:#999999" + offset="0.5" /> + <a:midPointstop + style="stop-color:#F2F2F2" + offset="0.28" /> + <a:midPointstop + style="stop-color:#F2F2F2" + offset="0.5" /> + <a:midPointstop + style="stop-color:#666666" + offset="1" /> + </linearGradient> + <linearGradient + x1="789.37" + y1="69.879997" + x2="791.03998" + y2="77.120003" + id="lg5874" + xlink:href="#g3292_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.204,0,0,1.263,-926.036,-60.001)" /> + <linearGradient + x1="786.65997" + y1="136.12" + x2="786.71002" + y2="134.33" + id="g3290_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1,-0.25,0,1,0,137.29)"> + <stop + style="stop-color:#d9d9d9;stop-opacity:1" + offset="0" + id="s6380" /> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="1" + id="s6382" /> + <a:midPointstop + style="stop-color:#D9D9D9" + offset="0" /> + <a:midPointstop + style="stop-color:#D9D9D9" + offset="0.5" /> + <a:midPointstop + style="stop-color:#B2B2B2" + offset="1" /> + </linearGradient> + <linearGradient + x1="786.65997" + y1="136.12" + x2="786.71002" + y2="134.33" + id="lg5878" + xlink:href="#g3290_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.204,-0.316,0,1.263,-926.036,113.351)" /> + <radialGradient + cx="1458.77" + cy="-5.0999999" + r="35.130001" + fx="1458.77" + fy="-5.0999999" + id="g3289_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.42,0,0,0.42,167.09,79.84)"> + <stop + style="stop-color:white;stop-opacity:1" + offset="0" + id="s6371" /> + <stop + style="stop-color:#999;stop-opacity:1" + offset="1" + id="s6373" /> + <a:midPointstop + style="stop-color:#FFFFFF" + offset="0" /> + <a:midPointstop + style="stop-color:#FFFFFF" + offset="0.5" /> + <a:midPointstop + style="stop-color:#999999" + offset="1" /> + </radialGradient> + <radialGradient + cx="1458.77" + cy="-5.0999999" + r="35.130001" + fx="1458.77" + fy="-5.0999999" + id="rg5881" + xlink:href="#g3289_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.505,0,0,0.53,-724.957,40.636)" /> + <radialGradient + cx="1612.98" + cy="-4.4699998" + r="36.580002" + fx="1612.98" + fy="-4.4699998" + id="g3288_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.34,0,0,0.36,238.56,86.87)"> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0" + id="s6362" /> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0.63999999" + id="s6364" /> + <stop + style="stop-color:#737373;stop-opacity:1" + offset="1" + id="s6366" /> + <a:midPointstop + style="stop-color:#E5E5E5" + offset="0" /> + <a:midPointstop + style="stop-color:#E5E5E5" + offset="0.5" /> + <a:midPointstop + style="stop-color:#B2B2B2" + offset="0.64" /> + <a:midPointstop + style="stop-color:#B2B2B2" + offset="0.5" /> + <a:midPointstop + style="stop-color:#737373" + offset="1" /> + </radialGradient> + <radialGradient + cx="1612.98" + cy="-4.4699998" + r="36.580002" + fx="1612.98" + fy="-4.4699998" + id="rg5884" + xlink:href="#g3288_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.408,0,0,0.448,-638.943,49.495)" /> + <radialGradient + cx="1470.5" + cy="-10.21" + r="33.290001" + fx="1470.5" + fy="-10.21" + id="g3287_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.42,0,0,0.42,167.09,79.84)"> + <stop + style="stop-color:#e5e5e5;stop-opacity:1" + offset="0" + id="s6347" /> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0.38999999" + id="s6349" /> + <stop + style="stop-color:#b1b1b1;stop-opacity:1" + offset="0.75" + id="s6351" /> + <stop + style="stop-color:#aaa;stop-opacity:1" + offset="0.88" + id="s6353" /> + <stop + style="stop-color:#9e9e9e;stop-opacity:1" + offset="0.97000003" + id="s6355" /> + <stop + style="stop-color:#999;stop-opacity:1" + offset="1" + id="s6357" /> + <a:midPointstop + style="stop-color:#E5E5E5" + offset="0" /> + <a:midPointstop + style="stop-color:#E5E5E5" + offset="0.5" /> + <a:midPointstop + style="stop-color:#B2B2B2" + offset="0.39" /> + <a:midPointstop + style="stop-color:#B2B2B2" + offset="0.87" /> + <a:midPointstop + style="stop-color:#999999" + offset="1" /> + </radialGradient> + <radialGradient + cx="1470.5" + cy="-10.21" + r="33.290001" + fx="1470.5" + fy="-10.21" + id="rg5887" + xlink:href="#g3287_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.505,0,0,0.53,-724.957,40.636)" /> + <pattern + patternTransform="matrix(0.592927,0,0,0.592927,78,462)" + id="cream-spots" + height="32" + width="32" + patternUnits="userSpaceOnUse"> + <g + transform="translate(-365.3146,-513.505)" + id="g3047"> + id="path2858" /> + <path + inkscape:label="#path2854" + sodipodi:nodetypes="czzzz" + style="fill:#e3dcc0" + id="path3060" + d="M 390.31462,529.50504 C 390.31462,534.47304 386.28262,538.50504 381.31462,538.50504 C 376.34662,538.50504 372.31462,534.47304 372.31462,529.50504 C 372.31462,524.53704 376.34662,520.50504 381.31462,520.50504 C 386.28262,520.50504 390.31462,524.53704 390.31462,529.50504 z " /> +</g> + </pattern> + <pattern + patternTransform="matrix(0.733751,0,0,0.733751,67,367)" + id="dark-cream-spots" + height="32" + width="32" + patternUnits="userSpaceOnUse"> + <g + transform="translate(-408.0946,-513.505)" + id="dark-cream-spot" + inkscape:label="#g3043"> + <path + sodipodi:nodetypes="czzzz" + style="fill:#c8c5ac" + d="M 433.09458,529.50504 C 433.09458,534.47304 429.06258,538.50504 424.09458,538.50504 C 419.12658,538.50504 415.09458,534.47304 415.09458,529.50504 C 415.09458,524.53704 419.12658,520.50504 424.09458,520.50504 C 429.06258,520.50504 433.09458,524.53704 433.09458,529.50504 z " + id="path2953" /> + </g> + </pattern> + <pattern + patternTransform="matrix(0.375,0,0,0.375,379,400)" + id="white-spots" + height="32" + width="32" + patternUnits="userSpaceOnUse"> + <g + transform="translate(-484.3997,-513.505)" + id="white-spot" + inkscape:label="#g3035"> + <path + style="opacity:0.25;fill:white" + id="path3033" + d="M 509.39967,529.50504 C 509.39967,534.47304 505.36767,538.50504 500.39967,538.50504 C 495.43167,538.50504 491.39967,534.47304 491.39967,529.50504 C 491.39967,524.53704 495.43167,520.50504 500.39967,520.50504 C 505.36767,520.50504 509.39967,524.53704 509.39967,529.50504 z " + sodipodi:nodetypes="czzzz" /> + </g> + </pattern> + <pattern + patternTransform="matrix(0.455007,0,0,0.455007,-5e-5,1.9e-5)" + id="black-spots" + height="32" + width="32" + patternUnits="userSpaceOnUse"> + <g + transform="translate(-448.3997,-513.505)" + id="black-spot" + inkscape:label="#g3039"> + <path + sodipodi:nodetypes="czzzz" + d="M 473.39967,529.50504 C 473.39967,534.47304 469.36767,538.50504 464.39967,538.50504 C 459.43167,538.50504 455.39967,534.47304 455.39967,529.50504 C 455.39967,524.53704 459.43167,520.50504 464.39967,520.50504 C 469.36767,520.50504 473.39967,524.53704 473.39967,529.50504 z " + id="path2961" + style="opacity:0.25;fill:black" /> + </g> + </pattern> + <linearGradient + x1="501.0903" + y1="-19.2544" + x2="531.85413" + y2="0.72390002" + id="linearGradient17334" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0" + id="stop17336" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0.51120001" + id="stop17338" /> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0.64609998" + id="stop17340" /> + <stop + style="stop-color:#16336e;stop-opacity:1" + offset="1" + id="stop17342" /> + <a:midPointStop + offset="0" + style="stop-color:#B4DAEA" /> + <a:midPointStop + offset="0.5" + style="stop-color:#B4DAEA" /> + <a:midPointStop + offset="0.5112" + style="stop-color:#B4DAEA" /> + <a:midPointStop + offset="0.5" + style="stop-color:#B4DAEA" /> + <a:midPointStop + offset="0.6461" + style="stop-color:#5387BA" /> + <a:midPointStop + offset="0.5" + style="stop-color:#5387BA" /> + <a:midPointStop + offset="1" + style="stop-color:#16336E" /> + </linearGradient> + <linearGradient + x1="415.73831" + y1="11.854" + x2="418.13361" + y2="18.8104" + id="linearGradient17426" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.8362,0.5206,-1.1904,0.992,147.62,-30.9374)"> + <stop + style="stop-color:#ccc;stop-opacity:1" + offset="0" + id="stop17428" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="1" + id="stop17430" /> + <a:midPointStop + offset="0" + style="stop-color:#CCCCCC" /> + <a:midPointStop + offset="0.5" + style="stop-color:#CCCCCC" /> + <a:midPointStop + offset="1" + style="stop-color:#F2F2F2" /> + </linearGradient> + <linearGradient + x1="478.21341" + y1="-131.9297" + x2="469.85818" + y2="-140.28481" + id="linearGradient17434" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.5592,0.829,-0.829,0.5592,101.3357,-104.791)"> + <stop + style="stop-color:#f3403f;stop-opacity:1" + offset="0" + id="stop17436" /> + <stop + style="stop-color:#d02a28;stop-opacity:1" + offset="0.37889999" + id="stop17438" /> + <stop + style="stop-color:#b21714;stop-opacity:1" + offset="0.77649999" + id="stop17440" /> + <stop + style="stop-color:#a6100c;stop-opacity:1" + offset="1" + id="stop17442" /> + <a:midPointStop + offset="0" + style="stop-color:#F3403F" /> + <a:midPointStop + offset="0.4213" + style="stop-color:#F3403F" /> + <a:midPointStop + offset="1" + style="stop-color:#A6100C" /> + </linearGradient> + <linearGradient + x1="502.70749" + y1="115.3013" + x2="516.39001" + y2="127.1953" + id="linearGradient17709" + xlink:href="#XMLID_1749_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9703,0.2419,-0.2419,0.9703,11.0227,-35.6159)" /> + <linearGradient + x1="506.09909" + y1="-11.5137" + x2="527.99609" + y2="2.7063999" + id="linearGradient17711" + xlink:href="#XMLID_1752_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <linearGradient + x1="516.57672" + y1="-15.769" + x2="516.57672" + y2="0.84280002" + id="linearGradient17713" + xlink:href="#XMLID_1753_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <linearGradient + x1="505.62939" + y1="-14.9526" + x2="527.49402" + y2="-0.7536" + id="linearGradient17715" + xlink:href="#XMLID_1756_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <linearGradient + x1="500.70749" + y1="-13.2441" + x2="513.46442" + y2="-2.1547" + id="linearGradient17717" + xlink:href="#XMLID_1757_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <linearGradient + x1="473.7681" + y1="209.17529" + x2="486.98099" + y2="213.2001" + id="linearGradient17721" + xlink:href="#XMLID_2274_" + gradientUnits="userSpaceOnUse" /> + <linearGradient + x1="481.23969" + y1="212.5742" + x2="472.92981" + y2="207.4967" + id="linearGradient17723" + xlink:href="#XMLID_2275_" + gradientUnits="userSpaceOnUse" /> + <linearGradient + x1="500.70749" + y1="-13.2441" + x2="513.46442" + y2="-2.1547" + id="linearGradient17416" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0" + id="stop17418" /> + <stop + style="stop-color:#96bad6;stop-opacity:1" + offset="1" + id="stop17420" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#96BAD6" + offset="1" /> + </linearGradient> + <defs + id="defs9929"> + <path + d="M 489.21,209.35 L 485.35,203.63 C 483.63,204.25 473.47,208.93 471.5,210.18 C 470.57,210.77 470.17,211.16 469.72,212.48 C 470.93,212.31 471.72,212.49 473.42,213.04 C 473.26,214.77 473.24,215.74 473.57,218.2 C 474.01,216.88 474.41,216.49 475.34,215.9 C 477.33,214.65 487.49,209.97 489.21,209.35 z " + id="XMLID_960_" /> + </defs> + <clipPath + id="clipPath17448"> + <use + id="use17450" + x="0" + y="0" + width="744.09448" + height="600" + xlink:href="#XMLID_960_" /> + </clipPath> + <linearGradient + x1="473.7681" + y1="209.17529" + x2="486.98099" + y2="213.2001" + id="linearGradient17452" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#f3403f;stop-opacity:1" + offset="0" + id="stop17454" /> + <stop + style="stop-color:#d02a28;stop-opacity:1" + offset="0.37889999" + id="stop17456" /> + <stop + style="stop-color:#b21714;stop-opacity:1" + offset="0.77649999" + id="stop17458" /> + <stop + style="stop-color:#a6100c;stop-opacity:1" + offset="1" + id="stop17460" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0.4213" /> + <a:midPointStop + style="stop-color:#A6100C" + offset="1" /> + </linearGradient> + <linearGradient + x1="481.23969" + y1="212.5742" + x2="472.92981" + y2="207.4967" + id="linearGradient17463" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#f3403f;stop-opacity:1" + offset="0" + id="stop17465" /> + <stop + style="stop-color:#d02a28;stop-opacity:1" + offset="0.37889999" + id="stop17467" /> + <stop + style="stop-color:#b21714;stop-opacity:1" + offset="0.77649999" + id="stop17469" /> + <stop + style="stop-color:#a6100c;stop-opacity:1" + offset="1" + id="stop17471" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0" /> + <a:midPointStop + style="stop-color:#F3403F" + offset="0.4213" /> + <a:midPointStop + style="stop-color:#A6100C" + offset="1" /> + </linearGradient> + <linearGradient + x1="481.23969" + y1="212.5742" + x2="472.92981" + y2="207.4967" + id="linearGradient17807" + xlink:href="#XMLID_2275_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(-177.1654,35.43307)" /> + <linearGradient + x1="473.7681" + y1="209.17529" + x2="486.98099" + y2="213.2001" + id="linearGradient17810" + xlink:href="#XMLID_2274_" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(-177.1654,35.43307)" /> + <linearGradient + x1="502.70749" + y1="115.3013" + x2="516.39001" + y2="127.1953" + id="linearGradient17812" + xlink:href="#XMLID_1749_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9703,0.2419,-0.2419,0.9703,11.0227,-35.6159)" /> + <linearGradient + x1="506.09909" + y1="-11.5137" + x2="527.99609" + y2="2.7063999" + id="linearGradient17814" + xlink:href="#XMLID_1752_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <linearGradient + x1="516.57672" + y1="-15.769" + x2="516.57672" + y2="0.84280002" + id="linearGradient17816" + xlink:href="#XMLID_1753_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <linearGradient + x1="505.62939" + y1="-14.9526" + x2="527.49402" + y2="-0.7536" + id="linearGradient17818" + xlink:href="#XMLID_1756_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <linearGradient + x1="502.70749" + y1="115.3013" + x2="516.39001" + y2="127.1953" + id="linearGradient17347" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9703,0.2419,-0.2419,0.9703,11.0227,-35.6159)"> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0" + id="stop17349" /> + <stop + style="stop-color:#96bad6;stop-opacity:1" + offset="1" + id="stop17351" /> + <a:midPointStop + offset="0" + style="stop-color:#5387BA" /> + <a:midPointStop + offset="0.5" + style="stop-color:#5387BA" /> + <a:midPointStop + offset="1" + style="stop-color:#96BAD6" /> + </linearGradient> + <linearGradient + x1="516.57672" + y1="-15.769" + x2="516.57672" + y2="0.84280002" + id="linearGradient17379" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b2b2b2;stop-opacity:1" + offset="0" + id="stop17381" /> + <stop + style="stop-color:#f2f2f2;stop-opacity:1" + offset="1" + id="stop17383" /> + <a:midPointStop + offset="0" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="0.5" + style="stop-color:#B2B2B2" /> + <a:midPointStop + offset="1" + style="stop-color:#F2F2F2" /> + </linearGradient> + <linearGradient + x1="502.70749" + y1="115.3013" + x2="516.39001" + y2="127.1953" + id="linearGradient17862" + xlink:href="#XMLID_1749_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.9703,0.2419,-0.2419,0.9703,-166.1427,-0.18283)" /> + <linearGradient + x1="505.62939" + y1="-14.9526" + x2="527.49402" + y2="-0.7536" + id="linearGradient17864" + xlink:href="#XMLID_1756_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <defs + id="defs3859"> + <polygon + points="465.54,213.52 481.94,217.46 482.74,216.71 487.46,198.05 471.08,194.07 470.26,194.83 465.54,213.52 " + id="XMLID_343_" /> + </defs> + <linearGradient + x1="471.0806" + y1="201.07761" + x2="481.91711" + y2="210.4977" + id="linearGradient17389" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#6498c1;stop-opacity:1" + offset="0.005618" + id="stop17391" /> + <stop + style="stop-color:#79a9cc;stop-opacity:1" + offset="0.2332" + id="stop17393" /> + <stop + style="stop-color:#a4cde2;stop-opacity:1" + offset="0.74049997" + id="stop17395" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="1" + id="stop17397" /> + <a:midPointStop + style="stop-color:#6498C1" + offset="5.618000e-003" /> + <a:midPointStop + style="stop-color:#6498C1" + offset="0.4438" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="1" /> + </linearGradient> + <clipPath + id="clipPath17400"> + <use + id="use17402" + x="0" + y="0" + width="744.09448" + height="600" + xlink:href="#XMLID_343_" /> + </clipPath> + <linearGradient + x1="505.62939" + y1="-14.9526" + x2="527.49402" + y2="-0.7536" + id="linearGradient17404" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0" + id="stop17406" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0.51120001" + id="stop17408" /> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0.64609998" + id="stop17410" /> + <stop + style="stop-color:#16336e;stop-opacity:1" + offset="1" + id="stop17412" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5112" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.6461" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#16336E" + offset="1" /> + </linearGradient> + <linearGradient + x1="506.09909" + y1="-11.5137" + x2="527.99609" + y2="2.7063999" + id="linearGradient17882" + xlink:href="#XMLID_1752_" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)" /> + <defs + id="defs3826"> + <polygon + points="463.52,216.14 480.56,220.24 481.36,219.5 483.03,202.04 469.05,196.69 468.24,197.45 463.52,216.14 " + id="XMLID_338_" /> + </defs> + <linearGradient + x1="468.2915" + y1="204.7612" + x2="479.39871" + y2="214.4166" + id="linearGradient17357" + gradientUnits="userSpaceOnUse"> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0" + id="stop17359" /> + <stop + style="stop-color:#96bad6;stop-opacity:1" + offset="1" + id="stop17361" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#96BAD6" + offset="1" /> + </linearGradient> + <clipPath + id="clipPath17364"> + <use + id="use17366" + x="0" + y="0" + width="744.09448" + height="600" + xlink:href="#XMLID_338_" /> + </clipPath> + <linearGradient + x1="506.09909" + y1="-11.5137" + x2="527.99609" + y2="2.7063999" + id="linearGradient17368" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.6868,0.4269,-0.9821,0.821,111.6149,-5.7901)"> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0" + id="stop17370" /> + <stop + style="stop-color:#b4daea;stop-opacity:1" + offset="0.51120001" + id="stop17372" /> + <stop + style="stop-color:#5387ba;stop-opacity:1" + offset="0.64609998" + id="stop17374" /> + <stop + style="stop-color:#16336e;stop-opacity:1" + offset="1" + id="stop17376" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5112" /> + <a:midPointStop + style="stop-color:#B4DAEA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.6461" /> + <a:midPointStop + style="stop-color:#5387BA" + offset="0.5" /> + <a:midPointStop + style="stop-color:#16336E" + offset="1" /> + </linearGradient> + <linearGradient + x1="296.4996" + y1="188.81061" + x2="317.32471" + y2="209.69398" + id="linearGradient2387" + xlink:href="#linearGradient2381" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.90776,0,0,0.90776,24.35648,49.24131)" /> + <linearGradient + x1="296.4996" + y1="188.81061" + x2="317.32471" + y2="209.69398" + id="linearGradient5105" + xlink:href="#linearGradient2381" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.90776,0,0,0.90776,24.35648,49.24131)" /> + <linearGradient + x1="296.4996" + y1="188.81061" + x2="317.32471" + y2="209.69398" + id="linearGradient5145" + xlink:href="#linearGradient2381" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.90776,0,0,0.90776,24.35648,49.24131)" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient2381" + id="linearGradient2371" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.90776,0,0,0.90776,24.35648,49.24131)" + x1="296.4996" + y1="188.81061" + x2="317.32471" + y2="209.69398" /> + </defs> + <g + transform="matrix(0.437808,-0.437808,0.437808,0.437808,-220.8237,43.55311)" + id="g5089"> + <path + d="M 8.4382985,-6.28125 C 7.8309069,-6.28125 4.125,-0.33238729 4.125,1.96875 L 4.125,28.6875 C 4.125,29.533884 4.7068159,29.8125 5.28125,29.8125 L 30.84375,29.8125 C 31.476092,29.8125 31.968751,29.319842 31.96875,28.6875 L 31.96875,23.46875 L 32.25,23.46875 C 32.74684,23.46875 33.156249,23.059339 33.15625,22.5625 L 33.15625,-5.375 C 33.15625,-5.8718398 32.74684,-6.28125 32.25,-6.28125 L 8.4382985,-6.28125 z " + transform="translate(282.8327,227.1903)" + style="fill:#5c5c4f;stroke:black;stroke-width:3.23021388;stroke-miterlimit:4;stroke-dasharray:none" + id="path5091" /> + <rect + width="27.85074" + height="29.369793" + rx="1.1414107" + ry="1.1414107" + x="286.96509" + y="227.63805" + style="fill:#032c87" + id="rect5093" /> + <path + d="M 288.43262,225.43675 L 313.67442,225.43675 L 313.67442,254.80655 L 287.29827,254.83069 L 288.43262,225.43675 z " + style="fill:white" + id="rect5095" /> + <path + d="M 302.44536,251.73726 C 303.83227,259.59643 301.75225,263.02091 301.75225,263.02091 C 303.99609,261.41329 305.71651,259.54397 306.65747,257.28491 C 307.62455,259.47755 308.49041,261.71357 310.9319,263.27432 C 310.9319,263.27432 309.33686,256.07392 309.22047,251.73726 L 302.44536,251.73726 z " + style="fill:#a70000;fill-opacity:1;stroke-width:2" + id="path5097" /> + <rect + width="25.241802" + height="29.736675" + rx="0.89682275" + ry="0.89682275" + x="290.73544" + y="220.92249" + style="fill:#809cc9" + id="rect5099" /> + <path + d="M 576.47347,725.93939 L 582.84431,726.35441 L 583.25121,755.8725 C 581.35919,754.55465 576.39694,752.1117 574.98889,754.19149 L 574.98889,727.42397 C 574.98889,726.60151 575.65101,725.93939 576.47347,725.93939 z " + transform="matrix(0.499065,-0.866565,0,1,0,0)" + style="fill:#4573b3;fill-opacity:1" + id="rect5101" /> + <path + d="M 293.2599,221.89363 L 313.99908,221.89363 C 314.45009,221.89363 314.81318,222.25673 314.81318,222.70774 C 315.02865,229.0361 295.44494,244.47124 292.44579,240.30491 L 292.44579,222.70774 C 292.44579,222.25673 292.80889,221.89363 293.2599,221.89363 z " + style="opacity:0.65536726;fill:url(#linearGradient2371);fill-opacity:1" + id="path5103" /> + </g> +</svg> diff --git a/doc/Revisor_Documentation/en-US/Appendix.xml b/doc/Revisor_Documentation/en-US/Appendix.xml deleted file mode 100644 index 01258fb..0000000 --- a/doc/Revisor_Documentation/en-US/Appendix.xml +++ /dev/null @@ -1,475 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<part id="Revisor_Documentation-Appendices"> - <title>Appendices</title> - - <appendix id="Revisor_Documentation-Appendix-Terminology" label="A"> - <title>Terminology</title> - <formalpara id="Revisor_Documentation-Appendix-Terminology-model"> - <title>Model</title> - <indexterm> - <primary>model</primary> - </indexterm> - <para> - A model in Revisor describes a product. - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Appendix-Terminology-package_manifest"> - <title>Package Manifest</title> - <indexterm> - <primary>Package Manifest</primary> - </indexterm> - <para> - A package manifest is the list of groups and packages to include or exclude from a transaction, in a kickstart configuration file. - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Appendix-Terminology-Remix"> - <title>Remix</title> - <indexterm> - <primary>Remix</primary> - </indexterm> - <para> - A Fedora Remix is a product based on Fedora, with Fedora packages and optionally, other packages as well, such as those from third-party repositories. - </para> - </formalpara> - - <formalpara id="Revisor_Documentation-Appendix-Terminology-Re-Spin"> - <title>Re-Spin</title> - <indexterm> - <primary>Re-Spin</primary> - <secondary>Fedora Unity Re-Spin</secondary> - </indexterm> - <para> - A Fedora Re-Spin is a product that is composed for the single purpose of including updated software packages into the product. It uses the same compose procedure as the media that the Fedora Project composes and releases, but includes updates. - </para> - </formalpara> - <para> - Fedora Unity releases Fedora Re-Spins every so often, twice or trice per release. - </para> - - <formalpara id="Revisor_Documentation-Appendix-Terminology-Spin"> - <title>Spin</title> - <indexterm> - <primary>Spin</primary> - </indexterm> - <para> - A Fedora Spin is a custom set of software packages, often for a specific audience. Spins include a KDE Spin, which contains KDE software packages rather then the Desktop spin, which is based around GNOME. Similarly, there are XFCE, LXDE, Sugar, Education, Games and Developer Spins. - </para> - </formalpara> - <para> - Fedora Spins have gone through the Spins Process (<ulink url="http://fedoraproject.org/wiki/Spins_Process" />), and have been approved trademark usage by the Fedora Project Board. - </para> - - <formalpara id="Revisor_Documentation-Appendix-Terminology-Package_Sack"> - <title>Package Sack</title> - <indexterm> - <primary>Package Sack</primary> - </indexterm> - <para> - When YUM creates a list of packages available from the repositories configured, including package metadata such as dependencies and provided capabilities for each package, YUM creates a PackageSack. It's basically a large bag with all Package Objects, filtered by compatible architectures for the configured architecture. - </para> - </formalpara> - </appendix> - - <appendix id="Revisor_Documentation-Appendix-Configuration_Reference" label="B"> - <title>Configuration Reference</title> - <para> - This is the configuration reference for Revisor. Options are listed in alphabetical order. - </para> - - <section id="Revisor_Documentation-Appendix-Configuration_Reference-Media_Options"> - <title>Configuration Options</title> - <para> - <table> - <title>Configuration Options</title> - <tgroup cols="4" title="Configuration Options"> - <colspec colname="column1" colwidth="1*" /> - <colspec colname="column25" colwidth="4*" /> - <colspec colname="column67" colwidth="2*" /> - <colspec colname="column89" colwidth="2*" /> - <thead> - <row> - <entry namest="column1" nameend="column89" align="center">Configuration Options</entry> - </row> - <row> - <entry namest="column1" nameend="column25">Configuration Directive</entry> - <entry namest="column67" nameend="column89">CLI Option</entry> - </row> - <row> - <entry namest="column1"> </entry> - <entry namest="column25">Possible Values</entry> - <entry>Default</entry> - <entry>Context</entry> - </row> - <row> - <entry namest="column1"> </entry> - <entry namest="column25" nameend="column67">Description</entry> - <entry namest="column89"> </entry> - </row> - </thead> - <tbody> - <row> - <entry namest="column1" nameend="column25"><literal>answer_yes</literal></entry> - <entry namest="column67" nameend="column89"><literal>-y</literal>, <literal>--yes</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Answer <emphasis>yes</emphasis> to all questions.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>clean_up</literal></entry> - <entry namest="column67" nameend="column89"><literal>--clean-up</literal></entry> - </row> - <row> - <entry namest="column25">0, 1, 2</entry> - <entry>1</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Should Revisor not clean up at all (0), clean up it's temporary build data (1), or everything -this includes the yum cache (2).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>copy_dir</literal></entry> - <entry namest="column67" nameend="column89"><literal>--copy-dir</literal></entry> - </row> - <row> - <entry namest="column25"><code>[dir]</code></entry> - <entry>False</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">A directory tree to copy onto the media created. In the case of installation media, the contents of the directory specified are copied onto <code>cdrom:/files/</code>. In the case of live media, the contents of the directory specified are copied onto the root filesystem of the live system.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>copy_local</literal></entry> - <entry namest="column67" nameend="column89"><literal>--copy-local</literal></entry> - </row> - <row> - <entry namest="column25"> </entry> - <entry>False</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Tell Revisor to copy files, even when they are local. This applies to relative corner-cases where the repositories or the <code>destination_directory</code> is mounted over NFS, and some actions cannot be performed.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>debuglevel</literal></entry> - <entry namest="column67" nameend="column89"><literal>-d</literal>, <literal>--debug</literal></entry> - </row> - <row> - <entry namest="column25">0 - 9</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">The level of debugging. 0 is the lowest debug level, whereas 9 is the highest. Revisor turns up the volume quickly. The logfile on debug level 9 may very easily become 20-30MB.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>destination_directory</literal></entry> - <entry namest="column67" nameend="column89"><literal>--destination-directory</literal></entry> - </row> - <row> - <entry namest="column25"><code>/srv/revisor/</code></entry> - <entry><code>[path]</code></entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">The destination directory for the product. Revisor creates a sub-directory with the name of the model used, and places the product in that directory.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>getsource</literal></entry> - <entry namest="column67" nameend="column89"><literal>--source</literal></entry> - </row> - <row> - <entry namest="column25"> </entry> - <entry>False</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to obtain the source along with the binary RPMs used. This is False by default, and therefor the source is not included by default. Note that if you are distributing your product to third parties, you need to be able to provide the sources along with the binary product.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>include_bootiso</literal></entry> - <entry namest="column67" nameend="column89"><literal> </literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to include the relatively large boot.iso on the optical installation media created. Setting this to 0 will still include boot.iso in the installation tree created (if configured with <code>media_installation_tree</code><footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Documentation-Compose_Process_Details" /> for more details.</para></footnote>)</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>kickstart_default</literal></entry> - <entry namest="column67" nameend="column89"><literal>--kickstart-default</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to set the isolinux.cfg entry that makes the installer use the kickstart included on the media, as a default.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>kickstart_exact</literal></entry> - <entry namest="column67" nameend="column89"><literal>--kickstart-exact</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Tells Revisor to ignore @core and @base groups (like with <code>%packages --nobase</code>) and only add what is in the package manifest.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>kickstart_exact_nevra</literal></entry> - <entry namest="column67" nameend="column89"><literal>--kickstart-exact-nevra</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Tells Revisor to only add what is in the package manifest. In addition, if the transaction changes (because of dependency resolving, for example), Revisor will stop composing.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>kickstart_file</literal></entry> - <entry namest="column67" nameend="column89"><literal>--kickstart</literal></entry> - </row> - <row> - <entry namest="column25"><code>[file]</code></entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">What kickstart file to use. When in CLI mode, this is a mandatory setting.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>kickstart_include</literal></entry> - <entry namest="column67" nameend="column89"><literal>--kickstart-include</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to include the kickstart on the media so that the installer may find it as <filename>cdrom:/ks.cfg</filename>.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>kickstart_save</literal></entry> - <entry namest="column67" nameend="column89"><literal>--kickstart-save</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Where to save the resulting kickstart. In GUI mode, when changes to the package set can be applied, saves those changes out into a new kickstart file.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_bluray_duallayer</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-bluray-dl</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create Bluray Duallayer installation media (47GiB).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_bluray</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-bluray</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create Bluray installation media (23GiB).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_bluray_duallayer</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-bluray-dl</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create Bluray Duallayer installation media (47GiB).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_cd</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-cd</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create CD installation media (685MiB).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_dvd</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-dvd</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create DVD installation media (4.3GiB).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_dvd_duallayer</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-dvd-dl</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create DVD Duallayer installation media (8.0GiB).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_tree</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-tree</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create a an installation tree<footnote><para>Note that the installation tree is always created. See <xref linkend="Revisor_Documentation-Compose_Process_Details" /> for more details.</para></footnote> (for publication over HTTP or FTP, or through Cobbler). No size limit.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_installation_unified</literal></entry> - <entry namest="column67" nameend="column89"><literal>--install-unified</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create a unified ISO, installation media (no size limit).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>media_live_optical</literal></entry> - <entry namest="column67" nameend="column89"><literal>--live-optical</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether to create Optical Live media (size unknown).</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>model</literal></entry> - <entry namest="column67" nameend="column89"><literal>--model</literal></entry> - </row> - <row> - <entry namest="column25"> </entry> - <entry><code>[model]</code></entry> - <entry>global</entry> - </row> - <row> - <entry namest="column25" nameend="column89">The model to use.</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>report_sizes</literal></entry> - <entry namest="column67" nameend="column89"><literal>--report_sizes</literal></entry> - </row> - <row> - <entry namest="column25">0, 1</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Report the sizes of RPM packages used. Lists the biggest packages in the transaction</entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>mode_respin</literal></entry> - <entry namest="column67" nameend="column89"><literal>--respin</literal></entry> - </row> - <row> - <entry namest="column25"> </entry> - <entry>False</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">Whether Revisor should operate in <emphasis>respin</emphasis> mode. See also <xref linkend="Revisor_Documentation-Compose_Process_Details-Respin_Mode" /></entry> - </row> - - <row> - <entry namest="column1" nameend="column25"><literal>working_directory</literal></entry> - <entry namest="column67" nameend="column89"><literal>-d</literal>, <literal>--debug</literal></entry> - </row> - <row> - <entry namest="column25">0 - 9</entry> - <entry>0</entry> - <entry>global, model</entry> - </row> - <row> - <entry namest="column25" nameend="column89">The level of debugging. 0 is the lowest debug level, whereas 9 is the highest. Revisor turns up the volume quickly. The logfile on debug level 9 may very easily become 20-30MB.</entry> - </row> - - </tbody> - </tgroup> - </table> - </para> - - </section> - - </appendix> - -</part> diff --git a/doc/Revisor_Documentation/en-US/Author_Group.xml b/doc/Revisor_Documentation/en-US/Author_Group.xml deleted file mode 100644 index 37b4bf5..0000000 --- a/doc/Revisor_Documentation/en-US/Author_Group.xml +++ /dev/null @@ -1,16 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<authorgroup> - <author> - <firstname>Jeroen</firstname> - <surname>van Meeuwen</surname> - <lineage>RHCE</lineage> - <affiliation> - <orgname>Fedora Project</orgname> - <orgdiv>Contributor</orgdiv> - </affiliation> - <email>kanarip(a)fedoraproject.org</email> - </author> -</authorgroup> diff --git a/doc/Revisor_Documentation/en-US/Book_Info.xml b/doc/Revisor_Documentation/en-US/Book_Info.xml deleted file mode 100644 index 7a9e7d8..0000000 --- a/doc/Revisor_Documentation/en-US/Book_Info.xml +++ /dev/null @@ -1,37 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<bookinfo id="Revisor_Documentation-Documentation"> - <title>Complete Reference</title> - <subtitle>Revisor Complete Installation, Configuration and Tweaking Reference</subtitle> - <productname>Revisor</productname> - <productnumber>2.1.5</productnumber> - - - <abstract> - <para> - This is Revisors upstream documentation. - </para> - </abstract> - <corpauthor> - <inlinemediaobject> - <imageobject> - <imagedata format='SVG' fileref="Common_Content/images/title_logo.svg" /> - </imageobject> - <textobject><phrase>Logo</phrase></textobject> - </inlinemediaobject> - </corpauthor> - <copyright> - <year>&YEAR;</year> - <holder>&HOLDER;</holder> - </copyright> - <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> -</bookinfo> - - - diff --git a/doc/Revisor_Documentation/en-US/Complete_Reference.ent b/doc/Revisor_Documentation/en-US/Complete_Reference.ent deleted file mode 100644 index 9282cde..0000000 --- a/doc/Revisor_Documentation/en-US/Complete_Reference.ent +++ /dev/null @@ -1,5 +0,0 @@ -<!ENTITY PRODUCT "Documentation"> -<!ENTITY BOOKID "Revisor_Documentation"> -<!ENTITY YEAR "2008"> -<!ENTITY HOLDER "Jeroen van Meeuwen"> - diff --git a/doc/Revisor_Documentation/en-US/Complete_Reference.xml b/doc/Revisor_Documentation/en-US/Complete_Reference.xml deleted file mode 100644 index 757504d..0000000 --- a/doc/Revisor_Documentation/en-US/Complete_Reference.xml +++ /dev/null @@ -1,27 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<book> - <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - - <xi:include href="Revisor_Documentation-Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Features.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Installation.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Configuration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Using_Kickstart.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Compose_Process_Details.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Plugins.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Tweaking_The_Build_Process.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Tips_and_Tricks.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Frequently_Asked_Questions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Testing.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <xi:include href="Revisor_Documentation-Development.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - - <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - <index /> - <xi:include href="Appendix.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - -</book> - diff --git a/doc/Revisor_Documentation/en-US/Preface.xml b/doc/Revisor_Documentation/en-US/Preface.xml deleted file mode 100644 index 02af0ea..0000000 --- a/doc/Revisor_Documentation/en-US/Preface.xml +++ /dev/null @@ -1,56 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<preface id="Revisor_Documentation-Preface"> - <title>Preface</title> - <para> - This is the documentation for Revisor, a utility to create and customize your own Linux distribution based on Fedora, Red Hat Enterprise Linux or CentOS. - </para> - - <section id="Revisor_Documentation-Preface-About_The_Contributors"> - <title>About the Contributors</title> - <formalpara> - <title>Author</title> - <para> - <emphasis>Jeroen van Meeuwen</emphasis> (RHCE, LPIC-2, MCP, CCNA) is currently a Senior System Engineer, specialized in Linux systems and Systems Architecture, working for Operator Groep Delft in The Netherlands. His experience with computers goes back to the early '90s, with a Philips P2000T being over a decade old, little tapes containing programs but most importantly games, and 16K memory cartridges. Since 1998, he has been involved with Red Hat Linux (5.2 at that time), and was an early adopter of Fedora Core Linux in November 2003, until his first real contributions to Free and Open Source Software were made in 2005. - </para> - </formalpara> - <para> - As a contributor to Free and Open Source Software within the Fedora community, amongst other programs, Jeroen has developed Revisor, a Python framework to build distributions with. With regards to Configuration Management, Jeroen currently maintains or co-maintains -amongst other packages- the entire stack of packages related to Puppet - </para> - - <formalpara> - <title>Contributors</title> - <para> - <emphasis>Jonathan Steffan</emphasis> is a community volunteer based in Colorado, USA, and has a long standing record within Fedora for packaging Zope (Web Application Server), Plone (Open Source Content Management System), providing compat-python2.4 packages for Fedora 7 and 8, and voluntarily administering the Fedora Unity servers, Zope and Plone instances, creating and further developing Revisor and pyJigdo. - </para> - </formalpara> - </section> - - <section id="Revisor_Documentation-Preface-About_Fedora_Unity"> - <title>About Fedora Unity</title> - <para> - The Fedora Unity Project consists of a group of concerned peers from within the Fedora community that strive to bring the best possible solutions to the community, in a consistent manner. This, amongst other things, resulted in extensive documentation on various topics often referred to on the Web, published under the Open Documentation License v1.0. - </para> - <para> - The Fedora Unity Project is a different project then the official Fedora Project. The people behind the Fedora Unity Project often contribute to the Fedora Project directly as well, but there's little to no bureaucracy in the Fedora Unity Project. Why do you think these Re-Spins are not released by the Fedora Project itself? - </para> - </section> - - <section id="Revisor_Documentation-Preface-About_This_Document"> - <title>About this Document</title> - <para> - This document is licensed under the Open Publication License version 1.0, which is available at <ulink url="http://www.opencontent.org/openpub/" />. You can get the latest version from <ulink url="http://kanarip.fedorapeople.org/Revisor_Documentation/en-US/pdf/Revisor_Doc…" /> (PDF), and it's sources live at <ulink url="http://git.fedorahosted.org/git/?p=revisor;a=tree;f=doc" />. - </para> - </section> - - <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - - <xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"> - <xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude"> - <xi:include href="Common_Content/Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> - </xi:fallback> - </xi:include> - -</preface> diff --git a/doc/Revisor_Documentation/en-US/Revision_History.xml b/doc/Revisor_Documentation/en-US/Revision_History.xml deleted file mode 100644 index 68432a0..0000000 --- a/doc/Revisor_Documentation/en-US/Revision_History.xml +++ /dev/null @@ -1,26 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<appendix id="appe-Publican-Revision_History"> - <title>Revision History</title> - <simpara> - <revhistory> - <revision> - <revnumber>1.0</revnumber> - <date></date> - <author> - <firstname></firstname> - <surname></surname> - <email></email> - </author> - <revdescription> - <simplelist> - <member></member> - </simplelist> - </revdescription> - </revision> - </revhistory> - </simpara> -</appendix> - diff --git a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Compose_Process_Details.xml b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Compose_Process_Details.xml deleted file mode 100644 index 64515ff..0000000 --- a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Compose_Process_Details.xml +++ /dev/null @@ -1,431 +0,0 @@ -<?xml version='1.0'?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ -]> - -<chapter id="Revisor_Documentation-Compose_Process_Details"> - <title>Compose Process Details</title> - <para> - This chapter lists the details of the compose process as well as dives deep into the features of Revisor. - </para> - - <section id="Revisor_Documentation-Compose_Process_Details-Overview"> - <title>Overview</title> - <titleabbrev id="Compose_Process_Details-Overview">Overview</titleabbrev> - <para> - Of course, the compose process for installation media is a little different then the compose process for live media. - </para> - <para> - When composing, Revisor starts out doing the following: - </para> - <para> - <itemizedlist> - <listitem> - <para> - Revisor initiates and loads plugins, options, and defaults. At this point, Revisor has a so-called <emphasis>ConfigStore</emphasis> that holds all options Revisor knows about. - </para> - </listitem> - <listitem> - <para> - Revisor reads the options from the command-line. - </para> - </listitem> - <listitem> - <para> - Revisor reads the configuration file specified with the <code>--config</code> command-line parameter, or uses it's builtin default, <filename>/etc/revisor/revisor.conf</filename>. - </para> - </listitem> - <listitem> - <para> - Revisor reads the global <code>[revisor]</code> section for all settings available in it's <emphasis>ConfigStore</emphasis> and sets those configured in the global section. Remember that if an option is not available in the <emphasis>ConfigStore</emphasis> but is configured in the global configuration section, it is ignored. - </para> - </listitem> - <listitem> - <para> - If a model is specified in the configuration file's global section <code>[revisor]</code>, Revisor will set that model to be used and loads it. - </para> - </listitem> - <listitem> - <para> - If a model has been specified on the command-line, with option <code>--model</code>, Revisor loads that model. - </para> - </listitem> - <listitem> - <para> - When loading the model, Revisor again iterates over all the settings that are in the <emphasis>ConfigStore</emphasis>, checks if the setting has been configured in the model section, and adjusts the setting in the <emphasis>ConfigStore</emphasis> if necessary. Again remember that if the <emphasis>ConfigStore</emphasis> does not know about one or the other option already, that setting is ignored. - </para> - </listitem> - <listitem> - <para> - Now that the defaults and configuration file settings have been applied to the <emphasis>ConfigStore</emphasis>, it is time for Revisor to look at the options specified on the command-line to see if you wanted to override anything. - </para> - </listitem> - <listitem> - <para> - While loading each configuration setting available in the global <code>[revisor]</code>, model-specific sections and/or command-line, Revisor checks every settings against a function that is specifically written to check such setting. For example, the label of an ISO cannot be longer th

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

revisor-devel June 2009