doc/Revisor_Documentation/en-US/Appendix.xml |
4
doc/Revisor_Documentation/en-US/Revisor_Documentation-Compose_Process_Details.xml |
139 +++++++++-
doc/Revisor_Documentation/en-US/Revisor_Documentation-Configuration.xml |
19 +
doc/Revisor_Documentation/en-US/Revisor_Documentation-Features.xml |
28 ++
doc/Revisor_Documentation/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml |
7
doc/Revisor_Documentation/en-US/Revisor_Documentation-Installation.xml |
6
doc/Revisor_Documentation/en-US/Revisor_Documentation-Plugins.xml |
75 +++--
unity/scripts/respin.sh |
8
8 files changed, 236 insertions(+), 50 deletions(-)
New commits:
commit 12bb9b3ec3bf651a09e3b386133b596b58a827b4
Merge: 7d8fe4f... e2b039b...
Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org>
Date: Sun Apr 26 17:01:41 2009 +0200
Merge branch 'master' of
ssh://git.fedorahosted.org/git/revisor
commit 7d8fe4fb8d714258c98366c58ae244f7071c668a
Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org>
Date: Sun Apr 26 16:58:38 2009 +0200
Update documentation
diff --git a/doc/Revisor_Documentation/en-US/Appendix.xml
b/doc/Revisor_Documentation/en-US/Appendix.xml
index 7ca7a75..01258fb 100644
--- a/doc/Revisor_Documentation/en-US/Appendix.xml
+++ b/doc/Revisor_Documentation/en-US/Appendix.xml
@@ -13,7 +13,7 @@
<primary>model</primary>
</indexterm>
<para>
- para
+ A model in Revisor describes a product.
</para>
</formalpara>
@@ -70,7 +70,7 @@
<primary>Package Sack</primary>
</indexterm>
<para>
- 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>
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
index c367f6c..64515ff 100644
--- a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Compose_Process_Details.xml
+++ b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Compose_Process_Details.xml
@@ -5,11 +5,12 @@
<chapter id="Revisor_Documentation-Compose_Process_Details">
<title>Compose Process Details</title>
<para>
- 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>
@@ -20,17 +21,22 @@
<itemizedlist>
<listitem>
<para>
- Revisor reads the options from the CLI and takes
<code>--config</code>, if specified.
+ 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 configuration file specified with
<code>--config</code>, or it's default,
<filename>/etc/revisor/revisor.conf</filename>.
+ Revisor reads the options from the command-line.
</para>
</listitem>
<listitem>
<para>
- Revisor reads the global <code>[revisor]</code>
section for all settings available and sets those configured in the global section.
+ 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>
@@ -45,7 +51,17 @@
</listitem>
<listitem>
<para>
- 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.
+ 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>
@@ -55,13 +71,56 @@
</listitem>
<listitem>
<para>
- In GUI mode however, if the settings are compatible, the GUI will
start.
+ 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>
@@ -289,7 +348,10 @@ for package in packages:
<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 satisfying
the dependency of other packages, rather then all packages satisfying said dependency
being installed.
+ 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.
@@ -297,12 +359,73 @@ for package in packages:
<note>
<title>Installation Procedure !== Upgrade Procedure</title>
<para>
- Note that an installation procedure is not the same as an upgrade
procedure.
+ 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/Revisor_Documentation/en-US/Revisor_Documentation-Configuration.xml
b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Configuration.xml
index a4e71dd..9d435bf 100644
--- a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Configuration.xml
+++ b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Configuration.xml
@@ -179,7 +179,7 @@ architecture = i386
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://localrepo/</literal>. This location may or may not be suitable
for you. If you have a local mirror, you might want to create an alias
(<emphasis>CNAME</emphasis>) for <literal>localrepo</literal> in
the domain name space you use. If <literal>localrepo</literal> does not
resolve, YUM will continue using the mirrorlist.
+ 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>
@@ -214,7 +214,10 @@ architecture = i386
<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 include more packages, or rebuild the installer
images, you will need to have a network connection and a mirror you can reach. There is no
list of required packages, since the packages change per release and may change in the
middle of the release cycle as well.
+ 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"
/>
@@ -224,7 +227,7 @@ architecture = i386
<section
id="Revisor_Documentation-Configuration-Yum_Repositories-Adding_Third_Party_Repositories">
<title>Adding Third Party Repositories</title>
<para>
- When adding a third party repository, ...
+ 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"
/>
@@ -234,7 +237,10 @@ architecture = i386
<section
id="Revisor_Documentation-Configuration-Yum_Repositories-Creating_Your_Own_Repository">
<title>Creating Your Own Repository</title>
<para>
- para, mention something about comps
+ 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.
@@ -263,7 +269,10 @@ architecture = i386
<section
id="Revisor_Documentation-Configuration-Command-line_Options">
<title>Command-line Options</title>
<para>
- 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>
diff --git a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Features.xml
b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Features.xml
index 7ed9028..6583398 100644
--- a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Features.xml
+++ b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Features.xml
@@ -81,6 +81,34 @@
<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">
diff --git
a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml
b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml
index 5ffdeb4..489d42a 100644
---
a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml
+++
b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Frequently_Asked_Questions.xml
@@ -8,6 +8,13 @@
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>
diff --git a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Installation.xml
b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Installation.xml
index cde3158..9997088 100644
--- a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Installation.xml
+++ b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Installation.xml
@@ -86,6 +86,12 @@
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>
diff --git a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Plugins.xml
b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Plugins.xml
index 7000895..adcca82 100644
--- a/doc/Revisor_Documentation/en-US/Revisor_Documentation-Plugins.xml
+++ b/doc/Revisor_Documentation/en-US/Revisor_Documentation-Plugins.xml
@@ -14,92 +14,105 @@
Plugins available from upstream, maintained by upstream
</para>
- <section
id="Revisor_Documentation-Plugins-Upstream-Cobbler_Module">
- <title>Cobbler Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Cobbler_Plugin">
+ <title>Cobbler Plugin</title>
<para>
- 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_Module">
- <title>Composer Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Composer_Plugin">
+ <title>Composer Plugin</title>
<para>
para
</para>
</section>
- <section
id="Revisor_Documentation-Plugins-Upstream-Delta_Module">
- <title>Delta Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Delta_Plugin">
+ <title>Delta Plugin</title>
<para>
- 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_Module">
- <title>GUI (Graphical User Interface) Module</title>
+ <section id="Revisor_Documentation-Plugins-Upstream-GUI_Plugin">
+ <title>GUI (Graphical User Interface) Plugin</title>
<para>
- para
+ Yes, the Graphical User Interface for Revisor is actually a plugin.
</para>
</section>
- <section id="Revisor_Documentation-Plugins-Upstream-HUB_Module">
- <title>HUB Module</title>
+ <section id="Revisor_Documentation-Plugins-Upstream-HUB_Plugin">
+ <title>HUB Plugin</title>
<para>
para
</para>
</section>
- <section
id="Revisor_Documentation-Plugins-Upstream-Isolinux_Module">
- <title>Isolinux Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Isolinux_Plugin">
+ <title>Isolinux Plugin</title>
+ <titleabbrev id="Isolinux_Plugin">Isolinux
Plugin</titleabbrev>
<para>
- 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_Module">
- <title>Jigdo Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Jigdo_Plugin">
+ <title>Jigdo Plugin</title>
<para>
para
</para>
</section>
- <section
id="Revisor_Documentation-Plugins-Upstream-Mock_Module">
- <title>Mock Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Mock_Plugin">
+ <title>Mock Plugin</title>
<para>
para
</para>
</section>
- <section
id="Revisor_Documentation-Plugins-Upstream-Rebrand_Module">
- <title>Rebrand Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Rebrand_Plugin">
+ <title>Rebrand Plugin</title>
<para>
- 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_Module">
- <title>Reuse Installer Images Module</title>
+ <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_Module">
- <title>Server Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Server_Plugin">
+ <title>Server Plugin</title>
<para>
para
</para>
</section>
- <section
id="Revisor_Documentation-Plugins-Upstream-Virtualization_Module">
- <title>Virtualization Module</title>
+ <section
id="Revisor_Documentation-Plugins-Upstream-Virtualization_Plugin">
+ <title>Virtualization Plugin</title>
<para>
para
</para>
</section>
- <section id="Revisor_Documentation-Plugins-Upstream-WUI_Module">
- <title>WUI (Web-based User Interface) Module</title>
+ <section id="Revisor_Documentation-Plugins-Upstream-WUI_Plugin">
+ <title>WUI (Web-based User Interface) Plugin</title>
<para>
para
</para>
commit 1a077d7d435c7ce0511ff09d40a2d9007e1f03a3
Author: Jeroen van Meeuwen (Fedora Unity) <kanarip(a)fedoraunity.org>
Date: Sun Apr 26 13:47:07 2009 +0200
Make sure the diffs end up in the right location no matter if they succeed
diff --git a/unity/scripts/respin.sh b/unity/scripts/respin.sh
index 2fb043d..8f8f8d2 100755
--- a/unity/scripts/respin.sh
+++ b/unity/scripts/respin.sh
@@ -348,11 +348,11 @@ for version in ${VERSIONS}; do
for i in `seq 28`; do
hist_date=`date --date="$i days ago"
+"%Y%m%d"`
- rpms_log_history=`find ${REVISORDIR}/$hist_date/$spin/log/ -name
"rpms-$spin.log" 2>/dev/null`
- rpms_log_today=`find ${REVISORDIR}/$datestamp/$spin/log/ -name
"rpms-$spin.log" 2>/dev/null`
+ rpms_log_history=`find ${REVISORDIR}/$hist_date/$spin/log/ -name
"rpms-$spin.log" 2>/dev/null | head -n 1`
+ rpms_log_today=`find ${REVISORDIR}/$datestamp/$spin/log/ -name
"rpms-$spin.log" 2>/dev/null | head -n 1`
if [ ! -z "$rpms_log_history" -a ! -z
"$rpms_log_today" ]; then
- `pwd`/unity/scripts/live-respin-size-diff.py
$rpms_log_history $rpms_log_today >
${TMPDIR:-/tmp}/rpms-diff-${hist_date}-$datestamp.log && \
- sudo mv
${TMPDIR:-/tmp}/rpms-diff-${hist_date}-$datestamp.log ${REVISORDIR}/$datestamp/$spin/log/
+ `pwd`/unity/scripts/live-respin-size-diff.py
$rpms_log_history $rpms_log_today >
${TMPDIR:-/tmp}/rpms-diff-${hist_date}-$datestamp.log 2>&1
+ sudo mv ${TMPDIR:-/tmp}/rpms-diff-${hist_date}-$datestamp.log
${REVISORDIR}/$datestamp/$spin/log/
fi
i=$[ $i + 1 ]
done