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@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@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@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