diff --git a/Manuals/RepoUserguide/repository-parts/Directories.docbook b/Manuals/RepoUserguide/repository-parts/Directories.docbook
new file mode 100644
index 0000000..d3bb0bc
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Directories.docbook
@@ -0,0 +1,22 @@
+
+
+ Directories
+
+ The CentOS Artwork Repository uses directories to organize
+ files and describe conceptual idea about corporate identity. Such
+ conceptual ideas are explained in each directory related
+ documentation entry.
+
+ In this chapter you'll learn what each directory inside The
+ CentOS Artwork Repository is for and so, how you can make use of
+ them. For that purpose, the following list of directories is
+ available for you to explore:
+
+ &dir-trunk;
+ &dir-trunk-identity;
+ &dir-trunk-identity-models;
+ &dir-trunk-identity-models-themes;
+ &dir-trunk-identity-models-themes-default;
+ &dir-trunk-manuals;
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Directories/trunk.docbook b/Manuals/RepoUserguide/repository-parts/Directories/trunk.docbook
new file mode 100644
index 0000000..1847e6c
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Directories/trunk.docbook
@@ -0,0 +1,12 @@
+
+
+ trunk
+
+ The trunk directory
+ structure implements the Subversion's trunk concept in a trunk,
+ branches, tags repository structure. The trunk directory structure provides
+ the main development line inside the CentOS Artwork
+ Repository.
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity.docbook b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity.docbook
new file mode 100644
index 0000000..b2ad8a1
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity.docbook
@@ -0,0 +1,210 @@
+
+
+ trunk/Identity
+
+ The trunk/Identity
+ directory implements The CentOS Project corporate
+ identity based on the The CentOS Project
+ mission and release
+ schema.
+
+ The CentOS Project exists to provide The CentOS
+ Distribution. Additionally, The CentOS Project provides The
+ CentOS Web and The CentOS Showroom to support and promote the
+ existence of The CentOS Distribution, respectively.
+
+ The
+ CentOS Project corporate identity is the ``persona'' of the
+ organization known as The CentOS Project. The CentOS Project
+ corporate identity plays a significant role in the way The CentOS
+ Project, as organization, presents itself to both internal and
+ external stakeholders. In general terms, The CentOS Project
+ corporate identity expresses the values and ambitions of The
+ CentOS Project organization, its business, and its
+ characteristics. The CentOS Project corporate identity provides
+ visibility, recognizability, reputation, structure and
+ identification to The CentOS Project organization by means of
+ corporate design, corporate
+ communication, and corporate
+ behaviour.
+
+ The
+ corporate design is focused on the effective communication of
+ corporate messages. Corporate messages are all the information
+ emitted from the corporation to a target audience. In order for
+ such communication to happen, it is required to put the messages
+ on a medium available for the target audience to react upon.
+ These media are know as corporate
+ manifestations, because the corporation manifests its
+ existence through them. The specific way used by the corporation
+ to set their messages on different media is what the corporate
+ design is about.
+
+ The amount of manifestations a corporation uses to
+ communicate its existence may very from one corporation to
+ another. In the very specific case of The CentOS Project, the
+ following corporate manifestations come to mind:
+
+
+
+
+ The CentOS Distribution — This corporate
+ manifestaion is built from SRPM packages. There are SRPM
+ packages that make a remarkable use of images (e.g., Anaconda,
+ Grub, Syslinux, Gdm, Kdm, Gsplash, Ksplash, Rhgb, Firstboot,
+ etc.), packages that make a moderate use of images and
+ packages that don't use images at all. Also, there are some
+ packages that make use of text-based information that need to
+ be changed, too (e.g., release notes, eula, the welcome page
+ of the web browser, etc.), in order for The CentOS Project to
+ comply the redistribution guidelines of its upstream provider.
+ The CentOS Distribution corporate manifestation focuses its
+ attention on SRPM packages that use images in a remarkable
+ way, specifically those packages that contain branding
+ information, in both image and textual format, from the
+ upstream provider. This way, replacing image and text-based
+ files, we implement the corporate design of The CentOS
+ Distribution corporate manifestations.
+
+
+
+
+ The CentOS Web — This corporate manifestation
+ exists to support The CentOS Distribution corporate
+ manifestation. The CentOS Web corporate manifestation covers
+ web applications used by The CentOS Project to manifest its
+ existence on the Internet. These web applications are free
+ software and come from different providers which distribute
+ their work with predefined visual styles. Frequently, these
+ predefined visual styles have no visual relation among
+ themselves and introduce some visual contraditions when they
+ all are put together. These visual contraditions need to be
+ removed in order to comply with The CentOS Project corporate
+ structure guidelines.
+
+
+
+
+ The CentOS Showroom — This corporate manifestation
+ exists to promote The CentOS Distribution. The CentOS
+ Showroom corporate manifestation covers industrial production
+ of objects branded by The CentOS Project (e.g., clothes,
+ stationery and installation media). These branded objects are
+ for distribution on social events and/or shops. They provide
+ a way of promotion and a route for commercialization that may
+ help to aliviate The CentOS Project expenses (e.g., hosting,
+ servers, full-time-developers, etc.), in a similar way as
+ donations may do.
+
+
+
+
+ The corporate manifestations above seem to cover all the
+ media required by The CentOS Project, as organization, to show its
+ existence. However, other corporate manifestations could be added
+ in the future, if needed, to cover different areas like building,
+ offices, transportation and whaterver medium The CentOS Project
+ thouches to show its existence.
+
+ The CentOS Project corporate communication is
+ based on community communication and takes
+ place through the following avenues:
+
+
+ The CentOS Chat (#centos, #centos-social},
+ #centos-devel on irc.freenode.net)
+ The CentOS Mailing Lists ().
+ The CentOS Forums ().
+ The CentOS Wiki ().
+ Social events, interviews, conferences, etc.
+
+
+
+
+ The CentOS Project corporate behaviour is based on
+ community behaviour which take place in .
+
+ The CentOS Project corporate structure is based on a
+ monolithic corporate visual identity
+ structure. In this configuration, one unique name and
+ one unique visual style is used in all corporate manifestations of
+ The CentOS Project.
+
+ In a monolithic corporate visual identity structure,
+ internal and external stakeholders feel a strong sensation of
+ uniformity, orientation, and identification with the organization.
+ No matter if you are visiting web sites, using the distribution,
+ or acting on social events, the one unique name and one unique
+ visual style connects them all to say: Hey! we are all
+ part of The CentOS Project.
+
+ Other corporate structures for The CentOS Project have been
+ considered as well. Such is the case of producing one different
+ visual style for each major release of The CentOS Distribution.
+ This structure isn't inconvenient at all, but some visual
+ contradictions could be introduced if it isn't applied correctly
+ and we need to be aware of it. To apply it correctly, we need to
+ know what The CentOS Project is made of.
+
+ The CentOS Project, as organization, is mainly made of (but
+ not limited to) three corporate manifestions: The CentOS
+ Distribution, The CentOS Web and The CentOS Showroom. Inside The
+ CentOS Distribution corporate manifestations, The CentOS Project
+ maintains near to four different major releases of The CentOS
+ Distribution (e.g., the operating system), parallely in time.
+ However, inside The CentOS Web visual manifestations, the content
+ is produced for no specific release information (e.g., there is no
+ a complete web site for each major release of The CentOS
+ Distribution individually, but one web site to cover them all).
+ Likewise, the content produced in The CentOS Showroom is created
+ for no release-specific at all, but for The CentOS Project in
+ general.
+
+ In order to produce the correct corporate structure for The
+ CentOS Project, we need to concider all the corporate
+ manifestations The CentOS Project is made of, not just one of
+ them. If one different visual style is used for each major
+ release of The CentOS Distribution, which one of those different
+ visual styles would be used to cover the remaining visual
+ manifestations The CentOS Project is made of (e.g., The CentOS Web
+ and The CentOS Showroom)?
+
+ Probably you are thinking, that's right, but The CentOS
+ Brand connects them all already, why would we need to join them up
+ into the same visual style too, isn't it more work to do, and
+ harder to maintain?
+
+ Harder to maintain, more work to do, probably. Specially
+ when you consider that The CentOS Project has proven stability and
+ consistency through time and, that, certainly, didn't come through
+ swinging magical wands or something but hardly working out to
+ automate tasks and providing maintainance through time. Said that,
+ we consider that The CentOS Project corporate structure must be
+ consequent with such stability and consistency tradition, beyond
+ the work it might require initially. It is true that The CentOS
+ Brand does connect all the visual manifestations it is present on,
+ but that connection would be stronger if one unique visual style
+ backups it, too. In fact, whatever thing you do to strength the
+ visual connection among The CentOS Project corporate
+ manifestations would be very good in favor of The CentOS Project
+ recognition.
+
+ Obviously, having just one visual style in all corporate
+ manifestations for eternity would be a very boring thing and would
+ give the impression of a visually dead project. So, there is no
+ problem on creating a brand new visual style for each new major
+ release of The CentOS Distribution, in order to refresh The CentOS
+ Distribution visual style; the problem itself is in not
+ propagating the brand new visual style created for the new release
+ of The CentOS Distribution to all other visual manifestations The
+ CentOS Project is made of, in a way The CentOS Project could be
+ recognized no matter what corporate manifestation be in front of
+ us. Such lack of uniformity is what introduces the visual
+ contradition we are precisely trying to solve by mean of themes
+ production in the CentOS Artwork Repository.
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models.docbook b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models.docbook
new file mode 100644
index 0000000..fba2893
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models.docbook
@@ -0,0 +1,4 @@
+
+ trunk/Identity/Models
+ ...
+
diff --git a/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models/Themes.docbook b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models/Themes.docbook
new file mode 100644
index 0000000..a2660e4
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models/Themes.docbook
@@ -0,0 +1,31 @@
+
+
+ trunk/Identity/Models/Themes
+
+ This directory implements the concept of themes'
+ design models.
+
+ Themes' design models provide the structural part of images
+ (e.g., dimensions, translation markers, position of each element
+ on the visible area, etc.) required by
+ centos-art.sh to perform theme rendition. The
+ provide the modeling characteristics for all the different visual
+ manifestations a theme is made of. Using themes' design models
+ reduce the time needed for propagating an artistic motif to
+ different visual manifestations.
+
+ In this directory, themes' design models are organized by
+ name. There is one directory for each theme's design model. Each
+ design model directory must be named as specified in . Inside themes' design models
+ directories, there is one directory for each visual manifestions a
+ theme is made of. These directories are named visual
+ manifestation directories and contain one or more SVG
+ files to describe the visual structure of that visual
+ manifestion.
+
+ Themes' design models are SVG files and
+ can be localized using the locale
functionality of
+ centos-art.sh script.
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook
new file mode 100644
index 0000000..30fe79b
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook
@@ -0,0 +1,16 @@
+
+
+ trunk/Identity/Models/Themes/Default
+
+ This directory implements the concept of themes'
+ default design models.
+
+ Themes' default design models provide the common structural
+ information (e.g., image dimensions, translation markers,
+ trademark position, etc.) the centos-art.sh
+ script uses to produce images when no other design model is
+ specified through the option at
+ rendition time.
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Directories/trunk/Manuals.docbook b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Manuals.docbook
new file mode 100644
index 0000000..f089182
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Directories/trunk/Manuals.docbook
@@ -0,0 +1,4 @@
+
+ trunk/Manuals
+ ...
+
diff --git a/Manuals/RepoUserguide/repository-parts/Introduction.docbook b/Manuals/RepoUserguide/repository-parts/Introduction.docbook
new file mode 100644
index 0000000..c0a4d95
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Introduction.docbook
@@ -0,0 +1,26 @@
+
+
+ Introduction
+
+ Welcome to The CentOS Artwork Repository
+ Manual.
+
+ The CentOS Artwork Repository Manual describes how The
+ CentOS Project corporate visual identity is organized and produced
+ inside the CentOS Artwork Repository (). If you are
+ looking for a comprehensive, task-oriented guide for understanding
+ how The CentOS Project corporate visual identity is produced, this
+ is the manual for you.
+
+ This guide assumes you have a basic understanding of The
+ CentOS Distribution. If you need help with CentOS, refer to the
+ help page on The CentOS Wiki () for a list of different
+ places you can find help.
+
+ &intro-history;
+ &intro-copying;
+ &intro-usage;
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Introduction/copying.docbook b/Manuals/RepoUserguide/repository-parts/Introduction/copying.docbook
new file mode 100644
index 0000000..1c679e0
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Introduction/copying.docbook
@@ -0,0 +1,91 @@
+
+
+ Copying conditions
+
+ Copyright © 2009, 2010, 2011 The CentOS Project
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+
+
+ Preamble
+
+ The CentOS Artwork Repository organizes files in a very
+ specific way to implement The CentOS Project corporate visual
+ identity. This very specific organization of files must be
+ considered part of centos-art.sh script, a bash
+ script that automate most of the frequent tasks inside the
+ repository.
+
+ The centos-art.sh script and the
+ organization of files it needs to work are not in the public
+ domain; they are copyrighted and there are restrictions on their
+ distribution, but these restrictions are designed to permit
+ everything that a good cooperating citizen would want to do. What
+ is not allowed is to try to prevent others from further sharing
+ any version of this program that they might get from you.
+
+ Specifically, we want to make sure that you have the right
+ to give away copies of centos-art.sh script and
+ the organization of files it needs to work, that you receive
+ source code or else can get it if you want it, that you can change
+ this program or use pieces of it in new free programs, and that
+ you know you can do these things.
+
+ To make sure that everyone has such rights, we have to
+ forbid you to deprive anyone else of these rights. For example,
+ if you distribute copies of the centos-art.sh
+ script, you must give the recipients all the rights that you have.
+ You must make sure that they, too, receive or can get the source
+ code. And you must tell them their rights.
+
+ Also, for our own protection, we must make certain that
+ everyone finds out that there is no warranty for the
+ centos-art.sh script. If this program is
+ modified by someone else and passed on, we want their recipients
+ to know that what they have is not what we distributed, so that
+ any problems introduced by others will not reflect on our
+ reputation.
+
+ The centos-art.sh script is released as a
+ GPL work. Individual packages used by
+ centos-art.sh script include their own licenses
+ and the centos-art.sh script license applies to
+ all packages that it does not clash with. If there is a clash
+ between the centos-art.sh script license and
+ individual package licenses, the individual package license
+ applies instead.
+
+ The precise conditions of the license for the
+ centos-art.sh script are found in the . This manual specifically is
+ covered by the .
+
+
+
+
+ The CentOS Brand
+
+ The CentOS Brand () is the main visual manifestaion of The
+ CentOS Project. The CentOS Project uses The CentOS Brand to
+ connect all its visual manifestions (e.g., GNU/Linux
+ Distributions, Websites, Stationery, etc.) and, this way, it
+ provides recognition among other similar projects available on the
+ Internet.
+
+ Both The CentOS Brand and all the visual manifestations that
+ derivate from it are available for you to study and propose
+ improvement around a good citizen's will at The CentOS Community
+ environment, but you are not allowed to redistribute them
+ elsewhere, without the given permission of The CentOS
+ Project.
+
+ If you need to redistribute either The CentOS Brand or any
+ visual manifestation derived from it, write your intentions to the
+ The CentOS Developers mailing list
+ (centos-devel@centos.org).
+
+
+
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Introduction/document-convenctions.docbook b/Manuals/RepoUserguide/repository-parts/Introduction/document-convenctions.docbook
new file mode 100644
index 0000000..8e12a51
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Introduction/document-convenctions.docbook
@@ -0,0 +1,147 @@
+
+
+ Document convenctions
+
+ In this manual the personal pronoun we
+ is used to repesent The CentOS Artwork SIG,
+ the group of persons that build The CentOS Project corporate
+ visual identity through the CentOS Artwork Repository.
+
+ In this manual, certain words are represented in different
+ fonts, typefaces, sizes, and weights. This highlighting is
+ systematic; different words are represented in the same style to
+ indicate their inclusion in a specific category. The types of
+ words that are represented this way include the following:
+
+
+
+ command
+
+ Linux commands (and other operating system
+ commands, when used) are represented this way. This
+ style should indicate to you that you can type the
+ word or phrase on the command line and press Enter to
+ invoke a command. Sometimes a command contains words
+ that would be displayed in a different style on their
+ own (such as file names). In these cases, they are
+ considered to be part of the command, so the entire
+ phrase is displayed as a command. For example:
+
+ Use the centos-art identity
+ --render='path/to/dir' command to produce
+ contents inside the trunk/Identity directory
+ structure.
+
+
+
+
+
+ file name
+
+ File names, directory names, paths, and RPM
+ package names are represented this way. This style
+ indicates that a particular file or directory exists
+ with that name on your system. Examples:
+
+ The init.sh file in
+ trunk/Scripts/Bash/Cli/
+ directory is the initialization script, written in
+ Bash, used to automate most of tasks in the
+ repository.
+
+ The centos-art command uses
+ the ImageMagick RPM package to
+ convert images from PNG format to other
+ formats.
+
+
+
+
+
+ key
+
+ A key on the keyboard is shown in this style.
+ For example:
+
+ To use TAB completion to list
+ particular files in a directory, type @command{ls},
+ then a character, and finally the Tab key. Your
+ terminal displays the list of files in the working
+ directory that begin with that character.
+
+
+
+
+ key-combination
+
+ A combination of keystrokes is represented in
+ this way. For example:
+
+ The CtrlAltBackspace
+ key combination exits your graphical session and
+ returns you to the graphical login screen or the
+ console.
+
+
+
+
+
+
+ computer output
+
+ Text in this style indicates text displayed to a
+ shell prompt such as error messages and responses to
+ commands. For example:
+
+ The ls command displays the
+ contents of a directory. For example:
+
+
+Config help_renameEntry.sh
+help_copyEntry.sh help_restoreCrossReferences.sh
+help_deleteCrossReferences.sh help_searchIndex.sh
+
+
+ The output returned in response to the command (in this
+ case, the contents of the directory) is shown in this
+ style.
+
+
+
+
+ Additionally, we use several different strategies to draw
+ your attention to certain pieces of information. In order of
+ urgency, these items are marked as a note, tip, important,
+ caution, or warning. For example:
+
+
+ Remember that Linux is case sensitive. In other words, a
+ rose is not a ROSE is not a rOsE.
+
+
+
+ The directory @file{/usr/share/doc/} contains additional
+ documentation for packages installed on your system.
+
+
+
+ If you modify the DHCP configuration file, the changes
+ do not take effect until you restart the DHCP daemon.
+
+
+
+ Do not perform routine tasks as root — use a
+ regular user account unless you need to use the root account
+ for system administration tasks.
+
+
+
+ Be careful to remove only the necessary partitions.
+ Removing other partitions could result in data loss or a
+ corrupted system environment.
+
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Introduction/history.docbook b/Manuals/RepoUserguide/repository-parts/Introduction/history.docbook
new file mode 100644
index 0000000..8d75b67
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Introduction/history.docbook
@@ -0,0 +1,148 @@
+
+
+ History
+
+ The CentOS Artwork Repository started around 2008 during a
+ discussion about how to automate the slide images of Anaconda, at
+ CentOS Developers mailing list (centos-devel@centos.org). In such
+ discussion, Ralph Angenendt rose up his hand to ask —Do you have
+ something to show?—.
+
+ To answer the question, I suggested a bash script which
+ combined SVG and SED files in order to produce PNG images in
+ different languages —together with the proposition of
+ creating a Subversion repository where translations and image
+ production could be distributed inside The CentOS
+ Community—.
+
+ Karanbirn Sighn considered the idea intresting and provided
+ the infrastructure necessary to support the effort. This way the
+ CentOS Artwork SIG (https://projects.centos.org/trac/artwork/) and
+ the CentOS Artwork Repository
+ (https://projects.centos.org/svn/artwork/) were officially
+ created.
+
+ Once the CentOS Artwork Repository was available, I uploaded
+ the bash script for rendering Anaconda slides; Ralph Angenendt
+ documented it very well; and people started to download working
+ copies of CentOS Artwork Repository to produce slide images in
+ their own languages.
+
+ Around 2009, the rendition script was at a very rustic state
+ where only slide images could be produced, so it was redesigned to
+ extend the image production to other areas, different from slide
+ images. In this configuration, one SVG file was used as input to
+ produce a translated instance of it which, in turn, was used to
+ produce one translated PNG image as output. The SVG translated
+ instance was created through SED replacement commands. The
+ translated PNG image was created from the SVG translated instance
+ using Inkscape command-line interface.
+
+ The repository directory structure was prepared to receive
+ the rendition script using design templates and translation files
+ in the same location. There was one directory structure for each
+ artwork that needed to be produced. In this configuration, if you
+ would want to produce the same artwork with a different visual
+ style or structure, it was needed to create a new directory
+ structure for it because both the image structure and the image
+ visual style were together in the design template.
+
+ The rendition script was moved to a common place and linked
+ from different directory structures. There was no need to have the
+ same code in different directory structures if it could be in just
+ one place and then be linked from different locations.
+
+ The concepts about corporate identity began to be
+ considered. As referece, it was used the book Corporate
+ Identity
by Wally Olins (1989) and Wikipedia related links
+ (e.g., ). This way, the rendition script main's goal becomes to:
+ automate production of a monolithic corporate visual identity
+ structure, based on the mission and the release schema of The
+ CentOS Project.
+
+ The repository directory structures began to be documented
+ inside by mean of flat text files. Later, documentation in flat
+ text files was moved onto LaTeX format and this way The
+ CentOS Artwork Repository Manual
is initiated.
+
+ Around 2010, the rendition script changed its name from
+ render.sh to centos-art.sh
+ and became a collection of functionalities where rendition was
+ just one among others (e.g., documenting and localizing).
+
+ The centos-art.sh was initialy conceived
+ to organize automation of most frequent tasks inside the
+ repository based in the conceptual idea of Unix toolbox:
+ create small and specialized tools that do one thing
+ well. This way, functionalities inside
+ centos-art.sh were identified and separated one
+ another. For example, when images were rendered, there was no need
+ to load functionalities related to documentation manual. This
+ layout moved us onto common functionalities and specific
+ functionalities inside centos-art.sh script.
+ Common functionalities are loaded when
+ centos-art.sh script is initiated and are
+ available to specific functionalities.
+
+ There was no need to have links all around the
+ repository if a command-line interface could be created (through
+ symbolic links, in the ~/bin directory) and be called
+ anywhere inside the repository as it would be a regular
+ command.
+
+ The centos-art.sh script was redesigned
+ to handle command-line options trough getopt
+ option parser.
+
+ The repository directory structure was updated to improve
+ the implementation of concepts related to corporate visual
+ identity. Specially in the area related to themes which were
+ divided into design models and
+ artistic motifs to eliminate the content
+ duplication produced by having both image structure and image
+ visual style in the same file. Now, both
+ centos-art.sh and repository directory
+ structure are able to produce themes as result of arbitrary
+ combinations between design models (structures) and artistic
+ motifs (visual styles).
+
+ In the documentation area, the documentation files in LaTeX
+ format were migrated to Texinfo format. In this configuration,
+ each directory structure in the repository has a documentation
+ entry associated in a Texinfo structure which can be read, edited
+ and administered (e.g., renamed, deleted, copied) interactively
+ throuch centos-art.sh. Additionally, the
+ texi2html program was used to produced XHTML
+ output customized by CSS from The CentOS Webenv.
+
+ Around 2011, the centos-art.sh script was
+ redesigned to start translating SVG and other XML-based files
+ (e.g., XHTML and Docbook files) through the
+ xml2po program and shell scripts files (e.g.,
+ Bash scripts) through GNU gettext tools. This
+ configuration provided a stronger interface for graphic designers,
+ translators and programmers to produce localized content. The SED
+ files are no longer used to handle translations.
+
+ The render
, help
and
+ locale
functionalities were consolidated as the most
+ frequent tasks performed inside the repository. Additionally, the
+ prepare
and tuneup
functionalities are
+ maintained as useful tasks.
+
+ The centos-art.sh script is updated to
+ organize functionalities in two groups: the administrative
+ functionalities
and the productive
+ functionalities
. The administrative functionalities cover
+ actions like: copying, deleting and renaming directory structures
+ inside the repository. Also, preparing your workstation for using
+ centos-art.sh script, making backups of the
+ distribution theme currently installed, installing themes created
+ inside repository and restoring themes from backup. On the other
+ hand, the productive functionalities cover actions like: content
+ rendition, content localization, content documentation and content
+ maintainance.
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Introduction/send-in-your-feedback.docbook b/Manuals/RepoUserguide/repository-parts/Introduction/send-in-your-feedback.docbook
new file mode 100644
index 0000000..198696e
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Introduction/send-in-your-feedback.docbook
@@ -0,0 +1,17 @@
+
+
+ Send in your feedback
+
+ If you find an error in the CentOS Artwork
+ Repository, or if you have thought of a way to make
+ this manual better, we would like to hear from you! Share your
+ suggestions in the appropriate mailing list
+ (http://lists.centos.org/) and/or bug tracker
+ (http://bugs.centos.org/).
+
+ When you make suggestion, try to be as specific as possible.
+ For example, if you have found an error in the manual, include the
+ section number and some of the surrounding text so we can find it
+ easily.
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Introduction/usage.docbook b/Manuals/RepoUserguide/repository-parts/Introduction/usage.docbook
new file mode 100644
index 0000000..235972f
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Introduction/usage.docbook
@@ -0,0 +1,369 @@
+
+
+ Usage convenctions
+
+ The CentOS Artwork Repository is supported by Subversion
+ (http://subversion.tigris.org/), a version control system which
+ allows you to keep old versions of files and directories (usually
+ source code), keep a log of who, when, and why changes occurred,
+ etc., like CVS, RCS or SCCS.
+
+ When using Subversion there is one "source repository" and
+ many "working copies" of that source repository. The working
+ copies are independent one another, can be distributed all around
+ the world and provide a local place for designers, documentors,
+ translators and programmers to perform their work in a
+ descentralized way. The source repository, on the other hand,
+ provides a central place for all independent working copies to
+ interchange data and provides the information required to permit
+ extracting previous versions of files at any time.
+
+
+
+ Policy
+
+ The CentOS Artwork Repository is a collaborative tool
+ that anyone can have access to. However, changing that tool in
+ any form is something that should be requested in the CentOS
+ Developers mailing list (centos-devel@centos.org). Generally,
+ people download working copies from CentOS Artwork Repository,
+ study the repository organization, make some changes in their
+ working copies, make some tests to verify such changes do work
+ the way expected and finally request access to commit them up
+ to the CentOS Artwork Repository (i.e., the source repository)
+ for others to benefit from them.
+
+ Once you've received access to commit your changes,
+ there is no need for you to request permission again to commit
+ other changes from your working copy to CentOS Artwork
+ Repository as long as you behave as a good
+ cooperating citizen. Otherwise, your rights to
+ commit changes might be temporarly revoked or permanently
+ banished.
+
+ As a good cooperating citizen one understand of a person
+ who respects the work already done by others and share ideas
+ with authors before changing relevant parts of their work,
+ specially in situations when the access required to realize
+ the changes has been granted already. Of course, there is a
+ time when conversation has taken place, the paths has been
+ traced and changing the work is so obvious that there is no
+ need for you to talk about it; that's because you already did,
+ you already built the trust to keep going. Anyway, the mailing
+ list mentioned above is available for sharing ideas in a way
+ that good relationship between community citizens could be
+ constantly balanced.
+
+ The relationship between community citizens is monitored
+ by repository administrators. Repository administrators are
+ responsible of granting that everything goes the way it needs
+ to go in order for the CentOS Artwork Repository to accomplish
+ its mission which is: to provide a colaborative tool for The
+ CentOS Community where The CentOS Project corporate visual
+ identity is built and maintained by The CentOS Community
+ itself.
+
+ It is also important to remember that all the program
+ and documentation source files inside CentOS Artwork
+ Repository must comply the terms of and
+ respectively in order for them to remain inside the
+ repository.
+
+
+
+
+
+ Work lines
+
+ Content production inside the repository is organized by
+ work lines. There are three major work
+ lines of production inside The CentOS Artwork Repository,
+ which are: Graphic design,
+ Documentation and
+ Localization. The specific way of
+ producing content inside each specific work line is
+ standardized by mean of centos-art.sh
+ script (which in turn, can be considered a work line by itself
+ [e.g., the Automation work line]). The
+ centos-art.sh script provides one specific
+ functionality for automating each major work line of content
+ production (e.g., render
for producing images,
+ help
for manage documentation, and
+ locale
for localizing contents).
+
+ The graphic design work line exists to cover brand
+ design, typography design and themes design mainly.
+ Additionally, some auxiliar areas like icon design,
+ illustration design, brushes design, patterns designs and
+ palettes of colors are also included here for completeness.
+ The graphic design work line is organized in the trunk/Identity directory.
+
+ The documentation work line exists to describe what each
+ directory inside the CentOS Artwork Repository is for, the
+ conceptual ideas behind them and, if possible, how automation
+ scripts make use of them. The documentation work line is
+ organized in the trunk/Manuals directory.
+
+ The localization work line exists to provide the
+ translation messages required to produce content in different
+ languages. Translation messages inside the repository are
+ stored as portable objects (e.g., .po, .pot) and machine
+ objects (.mo). The localization work line is organized in the
+ trunk/Locales
+ directory.
+
+ The automation work line exists to standardize content
+ production inside the working copies of CentOS Artwork
+ Repository. Here is developed the
+ centos-art.sh script, a bash script
+ specially designed to automate most frequent tasks (e.g.,
+ rendition, documentation and localization) inside the
+ repository. There is no need to type several tasks, time
+ after time, if they can be programmed into just one executable
+ script. The automation work line is organized in the
+ trunk/Scripts
+ directory.
+
+
+
+
+
+ Relation between directories
+
+ In order for automation scripts to produce content inside a
+ working copy of CentOS Artwork Repository, it is required that all
+ work lines be related somehow. The relation is used by automation
+ scripts to know where to retrive the information they need to work
+ with (e.g., design model, translation messages, output locations,
+ etc.). This kind of relation is built using two path
+ constructions named master paths and
+ auxiliar paths.
+
+ The master path points only to directories that contain
+ source files (e.g., SVG files) required to produce output base
+ content (e.g., PNG files) through automation scripts. Each master
+ path inside the repository may have several auxiliar paths
+ associated, but auxiliar paths can only have one master path
+ associated.
+
+ Master paths used for producing images through SVG rendition
+ are organized under trunk/Identity/Models directory
+ structure and the auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory
+ structures.
+
+ Auxiliar paths can point either to directories or files.
+ When an auxiliar path points to a directory, that directory
+ contains information that modifies somehow the content produced
+ from master paths (e.g., translation messages) or provides the
+ output information required to know where the content produced
+ from the master path should be stored. When an auxiliar path
+ points to a file, that file has no other purpose but to document
+ the master path it refers to.
+
+ Auxiliar paths should never be modified under any reason but
+ to satisfy the relationship with the master path. Liberal change
+ of auxiliar paths may suppress the conceptual idea they were
+ initially created for; and certainly, automation scripts may stop
+ working as expected.
+
+ The relationship between auxiliar paths and master paths is
+ built by combining the master path and the second level directory
+ structures of the repository. The master path is considered the
+ path identifier and the repository second level directory
+ structure is considered the common part of the path where the path
+ identifier is appended to. So, if we have the master path
+ trunk/Identity/Models/Brands, we'll
+ end up having, at least, the trunk/Identity/Images/Brands auxiliar
+ path for storing output files and, optionally, one path under
+ trunk/Manuals for storing
+ documentation and one path under trunk/Locales for storing
+ localizations.
+
+
+
+
+
+ Syncronizing paths
+
+ Once both master paths and their auxiliar paths have been
+ set, they shouldn't be changed. Assuming one master path must be
+ changed it is required that all related auxiliar paths be changed,
+ too. This is required in order for master paths to retain their
+ relation with auxiliar paths. This process of keeping relation
+ between master paths and auxiliar paths is known as path
+ syncronization.
+
+ Path syncronization is required for automation scripts to
+ know where to store final output, where to retrive translation
+ messages, documentation, and any information that might be
+ desired. If the relation between master paths and auxiliar paths
+ is lost, there is no way for centos-art.sh
+ script to know where to retrive the information it needs to work
+ with. Path syncronization is the way we use to organize and
+ extend the information stored in the repository.
+
+ Path syncronization may imply both movement of files and
+ replacement of content inside files. Movement of files is related
+ to actions like renaming files and directories inside the
+ repository. Replacement of content inside files is related to
+ actions like replacing information (e.g., paths information)
+ inside files in order to keep file contents and file locations
+ consistent one another.
+
+ The order followed to syncronize path information is very
+ important because the versioned nature of the repository files we
+ are working with. When a renaming action must be performed, we
+ avoid making replacements inside files first and file movements
+ later. This would require two commit actions: one for the files'
+ internal changes and another for the file movement itself.
+ Otherwise, we prefer to perform file movements first and file
+ internal replacements later. This way it is possible to commit
+ both changes as if they were just one.
+
+ There is no support for URLs actions inside
+ centos-art.sh script. The
+ centos-art.sh script is designed to work with
+ local files inside the working copy only. If you need to perform
+ URL actions directly, use Subversion commands
+ instead.
+
+ At this moment there is no full implementation of path
+ syncronization process inside centos-art.sh
+ script except by texinfo
backend of
+ help
functionality which provides a restricted
+ implementation of path syncronization to this specific area of
+ documentation through the ,
+ and options.
+ The plan for a full implementation of path syncronization would be
+ to create individual restricted implementations like this one for
+ other areas that demand it and then, create a higher implmentation
+ that combines all restricted implementations as needed. This way,
+ if we try to rename a repository directory the higer action will
+ define which are all the restricted actions that should be
+ performed in order for make a full path syncronization. For
+ example, if the directory we are renaming is part of graphic
+ design work line, it is required to syncronize related paths in
+ documentation and localization work lines. Likewise, if the
+ directory we are renaming is in documentation work line, it is
+ required to syncronize related paths in graphic design and
+ localization work lines. In all these cases, the direction used
+ for syncronizing paths must be from master path to auxiliar path
+ and never the opposite (i.e., rename the master path first and
+ auxiliar paths later).
+
+ A practical example, through which you can notice the
+ usefulness of path syncronization process, is what happen when
+ documentation entries are renamed (see section ...).
+
+
+
+
+
+ Extending repository organization
+
+ Occasionly, you may find that new components of The
+ CentOS Project corporate visual identity need to be added to
+ the repository in order to work them out. If that is the case,
+ the first question we need to ask ourselves, before start to
+ create directories blindly all over, is: What is the
+ right place to store it?
+
+ The best place to find answers is in The CentOS
+ Community (see page http://wiki.centos.org/Help), but going
+ there with hands empty is not good idea. It may give the
+ impression you don't really care about. Instead, consider the
+ following suggestions to find your own comprehension in order
+ to make your own propositions based on it.
+
+ When extending respository structure it is very useful
+ to bear in mind The CentOS Project corporate visual identity
+ structure, The CentOS Mission and The CentOS Release Schema.
+ The rest is a matter of choosing appropriate names. It is also
+ worth to know that each directory in the repository responds
+ to a conceptual idea that justifies its existence.
+
+ To build a directory structure inside the repository,
+ you need to define the conceptual idea first and later create
+ the directory, remembering that there are locations inside the
+ repository that define conceptual ideas you probably would
+ prefer to reuse. For example, the trunk/Identity/Images/Themes
+ directory stores theme artistic motifs, the trunk/Identity/Models/Themes
+ directory stores theme design models, the trunk/Manuals directory stores
+ documentation files, the trunk/Locales stores translation
+ messages, and the trunk/Scripts stores automation
+ scripts.
+
+ To better illustrate this desition process, you can
+ consider to examin the trunk/Identity/Images/Themes/TreeFlower/3
+ directory structure as example. This directory can be read
+ as: the theme development line of version 3
of
+ TreeFlower
artistic motif. Additional, we can
+ say that TreeFlower
artistic motif is part of
+ themes, as themes are part of The CentOS Project corporate
+ visual identity.
+
+ The relationship between conceptual ideas can be
+ stablished by reading each repository documentation entry
+ individually, from trunk directory to a deeper
+ directory in the path. For reading repository documentation
+ entries we use the help
functionality of
+ centos-art.sh script.
+
+
+
+
+
+ File names convenction
+
+ Inside the CentOS Artwork Repository, generally, file
+ names are all written in lowercase (e.g.,
+ 01-welcome.png,
+ splash.png,
+ anaconda_header.png, etc.) and directory
+ names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel
+ case (e.g., TreeFlower,
+ etc.).
+
+ In the very specific case of repository documentation
+ entries, file names follow the directory naming convenction.
+ This is because they are documenting directories and that is
+ something we want to remark. So, to better describe what we
+ are documenting, documentation entries follow the name
+ convenction used by the item they document.
+
+
+
+
+
+ Repository layout
+
+ The CentOS Artwork Repository is organized through a
+ convenctional trunk
, branches
+ and tags
layout. Explanation of each directory
+ inside the repository can be found in the chapter.
+
+
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Licenses/gfdl.docbook b/Manuals/RepoUserguide/repository-parts/Licenses/gfdl.docbook
new file mode 100644
index 0000000..789bb53
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Licenses/gfdl.docbook
@@ -0,0 +1,591 @@
+
+
+ GNU Free Documentation License
+
+ Version 1.2, November 2002
+
+ Copyright © 2000, 2001, 2002 Free Software Foundation,
+ Inc. 675 Mass Ave, Cambridge, MA 02139, USA
+
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+
+
+ Preamble
+
+ The purpose of this License is to make a manual,
+ textbook, or other functional and useful document
+ free
in the sense of freedom: to assure
+ everyone the effective freedom to copy and redistribute it,
+ with or without modifying it, either commercially or
+ noncommercially. Secondarily, this License preserves for the
+ author and publisher a way to get credit for their work, while
+ not being considered responsible for modifications made by
+ others.
+
+ This License is a kind of copyleft
, which
+ means that derivative works of the document must themselves be
+ free in the same sense. It complements the , which is a copyleft license
+ designed for free software.
+
+ We have designed this License in order to use it for
+ manuals for free software, because free software needs free
+ documentation: a free program should come with manuals
+ providing the same freedoms that the software does. But this
+ License is not limited to software manuals; it can be used for
+ any textual work, regardless of subject matter or whether it
+ is published as a printed book. We recommend this License
+ principally for works whose purpose is instruction or
+ reference.
+
+
+
+
+
+ Applicability and definitions
+
+ This License applies to any manual or other work, in any
+ medium, that contains a notice placed by the copyright holder
+ saying it can be distributed under the terms of this License.
+ Such a notice grants a world-wide, royalty-free license,
+ unlimited in duration, to use that work under the conditions
+ stated herein. The Document
, below, refers to
+ any such manual or work. Any member of the public is a
+ licensee, and is addressed as you
. You accept
+ the license if you copy, modify or distribute the work in a
+ way requiring permission under copyright law.
+
+ A
+ Modified Version
of the Document means any work
+ containing the Document or a portion of it, either copied
+ verbatim, or with modifications and/or translated into another
+ language.
+
+ A
+ Secondary Section
is a named appendix or a
+ front-matter section of the Document that deals exclusively
+ with the relationship of the publishers or authors of the
+ Document to the Document's overall subject (or to related
+ matters) and contains nothing that could fall directly within
+ that overall subject. (Thus, if the Document is in part a
+ textbook of mathematics, a may not explain any mathematics.) The relationship could be
+ a matter of historical connection with the subject or with
+ related matters, or of legal, commercial, philosophical,
+ ethical or political position regarding them.
+
+ The Invariant Sections
are certain
+ whose titles are
+ designated, as being those of Invariant Sections, in the
+ notice that says that the Document is released under this
+ License. If a section does not fit the above definition of
+ Secondary then it is not allowed to be designated as
+ Invariant. The Document may contain zero Invariant Sections.
+ If the Document does not identify any Invariant Section then
+ there are none.
+
+ The
+ Cover Texts
are certain short passages of text
+ that are listed, as Front-Cover Texts or Back-Cover Texts, in
+ the notice that says that the Document is released under this
+ License. A Front-Cover Text may be at most 5 words, and a
+ Back-Cover Text may be at most 25 words.
+
+ A
+ Transparent
copy of the Document means a
+ machine-readable copy, represented in a format whose
+ specification is available to the general public, that is
+ suitable for revising the document straightforwardly with
+ generic text editors or (for images composed of pixels)
+ generic paint programs or (for drawings) some widely available
+ drawing editor, and that is suitable for input to text
+ formatters or for automatic translation to a variety of
+ formats suitable for input to text formatters. A copy made in
+ an otherwise file format whose
+ markup, or absence of markup, has been arranged to thwart or
+ discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of
+ text. A copy that is not
is called Opaque
.
+
+ Examples of suitable formats for copies
+ include plain ASCII without markup, Texinfo input format,
+ LaTeX input format, SGML or XML using a publicly available
+ DTD, and standard-conforming simple HTML, PostScript or PDF
+ designed for human modification. Examples of transparent
+ image formats include PNG, XCF and JPG. Opaque formats
+ include proprietary formats that can be read and edited only
+ by proprietary word processors, SGML or XML for which the DTD
+ and/or processing tools are not generally available, and the
+ machine-generated HTML, PostScript or PDF produced by some
+ word processors for output purposes only.
+
+ The Title
+ Page
means, for a printed book, the title page itself,
+ plus such following pages as are needed to hold, legibly, the
+ material this License requires to appear in the title page.
+ For works in formats which do not have any title page as such,
+ Title Page
means the text near the most
+ prominent appearance of the work's title, preceding the
+ beginning of the body of the text.
+
+ A section Entitled XYZ
means a named
+ subunit of the Document whose title either is precisely XYZ or
+ contains XYZ in parentheses following text that translates XYZ
+ in another language. (Here XYZ stands for a specific section
+ name mentioned below, such as Acknowledgements
,
+ Dedications
, Endorsements
, or
+ History
.) To Preserve the Title
+ of such a section when you modify the Document means that it
+ remains a section Entitled XYZ
according to
+ this definition.
+
+ The Document may include Warranty Disclaimers next to
+ the notice which states that this License applies to the
+ Document. These Warranty Disclaimers are considered to be
+ included by reference in this License, but only as regards
+ disclaiming warranties: any other implication that these
+ Warranty Disclaimers may have is void and has no effect on the
+ meaning of this License.
+
+
+
+
+
+ Verbatim copying
+
+ You may copy and distribute the Document in any medium,
+ either commercially or noncommercially, provided that this
+ License, the copyright notices, and the license notice saying
+ this License applies to the Document are reproduced in all
+ copies, and that you add no other conditions whatsoever to
+ those of this License. You may not use technical measures to
+ obstruct or control the reading or further copying of the
+ copies you make or distribute. However, you may accept
+ compensation in exchange for copies. If you distribute a
+ large enough number of copies you must also follow the
+ conditions in section .
+
+ You may also lend copies, under the same conditions
+ stated above, and you may publicly display copies.
+
+
+
+
+
+ Copying in quantity
+
+ If you publish printed copies (or copies in media that
+ commonly have printed covers) of the Document, numbering more
+ than 100, and the Document's license notice requires Cover
+ Texts, you must enclose the copies in covers that carry,
+ clearly and legibly, all these :
+ Front-Cover Texts on the front cover, and Back-Cover Texts on
+ the back cover. Both covers must also clearly and legibly
+ identify you as the publisher of these copies. The front
+ cover must present the full title with all words of the title
+ equally prominent and visible. You may add other material on
+ the covers in addition. Copying with changes limited to the
+ covers, as long as they preserve the title of the Document and
+ satisfy these conditions, can be treated as verbatim copying
+ in other respects.
+
+ If the required texts for either cover are too
+ voluminous to fit legibly, you should put the first ones
+ listed (as many as fit reasonably) on the actual cover, and
+ continue the rest onto adjacent pages.
+
+ If you publish or distribute Opaque copies of the
+ Document numbering more than 100, you must either include a
+ machine-readable copy along with each Opaque copy,
+ or state in or with each Opaque copy a computer-network
+ location from which the general network-using public has
+ access to download using public-standard network protocols a
+ complete copy of the Document, free of added
+ material. If you use the latter option, you must take
+ reasonably prudent steps, when you begin distribution of
+ Opaque copies in quantity, to ensure that this
+ copy will remain thus accessible at the stated location until
+ at least one year after the last time you distribute an Opaque
+ copy (directly or through your agents or retailers) of that
+ edition to the public.
+
+ It is requested, but not required, that you contact the
+ authors of the Document well before redistributing any large
+ number of copies, to give them a chance to provide you with an
+ updated version of the Document.
+
+
+
+
+
+ Modifications
+
+ You may copy and distribute a of the Document under the
+ conditions of sections and above,
+ provided that you release the under precisely this License, with the filling the role of the
+ Document, thus licensing distribution and modification of the
+ to whoever possesses a
+ copy of it. In addition, you must do these things in the
+ :
+
+
+
+
+ Use in the (and on
+ the covers, if any) a title distinct from that of the
+ Document, and from those of previous versions (which
+ should, if there were any, be listed in the History
+ section of the Document). You may use the same title
+ as a previous version if the original publisher of
+ that version gives permission.
+
+
+ List on the , as
+ authors, one or more persons or entities responsible
+ for authorship of the modifications in the , together with at least
+ five of the principal authors of the Document (all of
+ its principal authors, if it has fewer than five),
+ unless they release you from this requirement.
+
+
+
+ State on the the
+ name of the publisher of the , as the
+ publisher.
+
+
+
+ Preserve all the copyright notices of the
+ Document.
+
+
+
+ Add an appropriate copyright notice for your
+ modifications adjacent to the other copyright
+ notices.
+
+
+
+ Include, immediately after the copyright
+ notices, a license notice giving the public permission
+ to use the under the terms of this
+ License, in the form shown in the Addendum
+ below.
+
+
+
+ Preserve in that license notice the full lists
+ of and required
+ given in the Document's
+ license notice.
+
+
+
+ Include an unaltered copy of this License.
+
+
+
+ Preserve the section Entitled
+ History
, Preserve its Title, and add to
+ it an item stating at least the title, year, new
+ authors, and publisher of the as given on the . If there is no section
+ Entitled History
in the Document, create
+ one stating the title, year, authors, and publisher of
+ the Document as given on its , then add an item describing the as stated in the previous
+ sentence.
+
+
+
+ Preserve the network location, if any, given in
+ the Document for public access to a copy of the Document, and
+ likewise the network locations given in the Document
+ for previous versions it was based on. These may be
+ placed in the History
section. You may
+ omit a network location for a work that was published
+ at least four years before the Document itself, or if
+ the original publisher of the version it refers to
+ gives permission.
+
+
+
+ For any section Entitled
+ Acknowledgements
or
+ Dedications
, Preserve the Title of the
+ section, and preserve in the section all the substance
+ and tone of each of the contributor acknowledgements
+ and/or dedications given therein.
+
+
+
+ Preserve all the of the Document,
+ unaltered in their text and in their titles. Section
+ numbers or the equivalent are not considered part of
+ the section titles.
+
+
+
+ Delete any section Entitled
+ Endorsements
. Such a section may not
+ be included in the .
+
+
+
+ Do not retitle any existing section to be
+ Entitled Endorsements
or to conflict in
+ title with any .
+
+
+ Preserve any Warranty Disclaimers.
+
+
+
+
+ If the includes new
+ front-matter sections or appendices that qualify as and contain no material copied
+ from the Document, you may at your option designate some or
+ all of these sections as invariant. To do this, add their
+ titles to the list of in the 's license notice. These titles
+ must be distinct from any other section titles.
+
+ You may add a section Entitled
+ Endorsements
, provided it contains nothing but
+ endorsements of your by various
+ parties–for example, statements of peer review or that
+ the text has been approved by an organization as the
+ authoritative definition of a standard.
+
+ You may add a passage of up to five words as a
+ Front-Cover Text, and a passage of up to 25 words as a
+ Back-Cover Text, to the end of the list of in the . Only one passage of
+ Front-Cover Text and one of Back-Cover Text may be added by
+ (or through arrangements made by) any one entity. If the
+ Document already includes a cover text for the same cover,
+ previously added by you or by arrangement made by the same
+ entity you are acting on behalf of, you may not add another;
+ but you may replace the old one, on explicit permission from
+ the previous publisher that added the old one.
+
+ The author(s) and publisher(s) of the Document do not by
+ this License give permission to use their names for publicity
+ for or to assert or imply endorsement of any .
+
+
+
+
+
+ Combining documents
+
+ You may combine the Document with other documents
+ released under this License, under the terms defined in
+ section above for
+ modified versions, provided that you include in the
+ combination all of the of
+ all of the original documents, unmodified, and list them all
+ as of your combined work
+ in its license notice, and that you preserve all their
+ Warranty Disclaimers.
+
+ The combined work need only contain one copy of this
+ License, and multiple identical may be replaced with a single
+ copy. If there are multiple with the same name but
+ different contents, make the title of each such section unique
+ by adding at the end of it, in parentheses, the name of the
+ original author or publisher of that section if known, or else
+ a unique number. Make the same adjustment to the section
+ titles in the list of in
+ the license notice of the combined work.
+
+ In the combination, you must combine any sections
+ Entitled History
in the various original
+ documents, forming one section Entitled
+ History
; likewise combine any sections Entitled
+ Acknowledgements
, and any sections Entitled
+ Dedications
. You must delete all sections
+ Entitled Endorsements
.
+
+
+
+
+
+ Collection of documents
+
+ You may make a collection consisting of the Document and
+ other documents released under this License, and replace the
+ individual copies of this License in the various documents
+ with a single copy that is included in the collection,
+ provided that you follow the rules of this License for
+ verbatim copying of each of the documents in all other
+ respects.
+
+ You may extract a single document from such a
+ collection, and distribute it individually under this License,
+ provided you insert a copy of this License into the extracted
+ document, and follow this License in all other respects
+ regarding verbatim copying of that document.
+
+
+
+
+
+ Aggregation with independent works
+
+ A compilation of the Document or its derivatives with
+ other separate and independent documents or works, in or on a
+ volume of a storage or distribution medium, is called an
+ aggregate
if the copyright resulting from the
+ compilation is not used to limit the legal rights of the
+ compilation's users beyond what the individual works permit.
+ When the Document is included in an aggregate, this License
+ does not apply to the other works in the aggregate which are
+ not themselves derivative works of the Document.
+
+ If the Cover Text requirement of section is applicable to these
+ copies of the Document, then if the Document is less than one
+ half of the entire aggregate, the Document's may be placed on covers that bracket
+ the Document within the aggregate, or the electronic
+ equivalent of covers if the Document is in electronic form.
+ Otherwise they must appear on printed covers that bracket the
+ whole aggregate.
+
+
+
+
+
+ Translations
+
+ Translation is considered a kind of modification, so you
+ may distribute translations of the Document under the terms of
+ section . Replacing
+ with translations
+ requires special permission from their copyright holders, but
+ you may include translations of some or all in addition to the original
+ versions of these . You
+ may include a translation of this License, and all the license
+ notices in the Document, and any Warranty Disclaimers,
+ provided that you also include the original English version of
+ this License and the original versions of those notices and
+ disclaimers. In case of a disagreement between the
+ translation and the original version of this License or a
+ notice or disclaimer, the original version will
+ prevail.
+
+ If a section in the Document is Entitled
+ Acknowledgements
, Dedications
,
+ or History
, the requirement (section ) to Preserve its Title
+ (section ) will
+ typically require changing the actual title.
+
+
+
+
+
+ Termination
+
+ You may not copy, modify, sublicense, or distribute the
+ Document except as expressly provided for under this License.
+ Any other attempt to copy, modify, sublicense or distribute
+ the Document is void, and will automatically terminate your
+ rights under this License. However, parties who have received
+ copies, or rights, from you under this License will not have
+ their licenses terminated so long as such parties remain in
+ full compliance.
+
+
+
+
+
+ Future Revisions of this License
+
+ The Free Software Foundation may publish new, revised
+ versions of the GNU Free Documentation License from time to
+ time. Such new versions will be similar in spirit to the
+ present version, but may differ in detail to address new
+ problems or concerns. See .
+
+ Each version of the License is given a distinguishing
+ version number. If the Document specifies that a particular
+ numbered version of this License or any later
+ version
applies to it, you have the option of
+ following the terms and conditions either of that specified
+ version or of any later version that has been published (not
+ as a draft) by the Free Software Foundation. If the Document
+ does not specify a version number of this License, you may
+ choose any version ever published (not as a draft) by the Free
+ Software Foundation.
+
+
+
+
+
+ How to use this License for your documents
+
+ To use this License in a document you have written,
+ include a copy of the License in the document and put the
+ following copyright and license notices just after the title
+ page:
+
+
+ Copyright (C) YEAR YOUR NAME.
+
+ Permission is granted to copy, distribute and/or modify this
+ document under the terms of the GNU Free Documentation License,
+ Version 1.2 or any later version published by the Free Software
+ Foundation; with no Invariant Sections, no Front-Cover Texts, and
+ no Back-Cover Texts. A copy of the license is included in the
+ section entitled GNU Free Documentation License
.
+
+
+ If you have ,
+ Front-Cover Texts and Back-Cover Texts, replace the
+ with...Texts
. line with this:
+
+
+ with the Invariant Sections being LIST THEIR TITLES, with the
+ Front-Cover Texts being LIST, and with the Back-Cover Texts being
+ LIST.
+
+
+ If you have
+ without , or some other
+ combination of the three, merge those two alternatives to suit
+ the situation.
+
+ If your document contains nontrivial examples of program
+ code, we recommend releasing these examples in parallel under
+ your choice of free software license, such as the GNU General
+ Public License, to permit their use in free software.
+
+
+
+
diff --git a/Manuals/RepoUserguide/repository-parts/Licenses/gpl.docbook b/Manuals/RepoUserguide/repository-parts/Licenses/gpl.docbook
new file mode 100644
index 0000000..3ddcafc
--- /dev/null
+++ b/Manuals/RepoUserguide/repository-parts/Licenses/gpl.docbook
@@ -0,0 +1,485 @@
+
+
+ GNU General Public License
+
+ Version 2, June 1991
+
+ Copyright © 1989, 1991 Free Software Foundation, Inc.
+ 675 Mass Ave, Cambridge, MA 02139, USA
+
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+
+
+ Preamble
+
+ The licenses for most software are designed to take away
+ your freedom to share and change it. By contrast, the GNU General
+ Public License is intended to guarantee your freedom to share and
+ change free software–to make sure the software is free for
+ all its users. This General Public License applies to most of the
+ Free Software Foundation's software and to any other program whose
+ authors commit to using it. (Some other Free Software Foundation
+ software is covered by the GNU Library General Public License
+ instead.) You can apply it to your programs, too.
+
+ When we speak of free software, we are referring to freedom,
+ not price. Our General Public Licenses are designed to make sure
+ that you have the freedom to distribute copies of free software
+ (and charge for this service if you wish), that you receive source
+ code or can get it if you want it, that you can change the
+ software or use pieces of it in new free programs; and that you
+ know you can do these things.
+
+ To protect your rights, we need to make restrictions that
+ forbid anyone to deny you these rights or to ask you to surrender
+ the rights. These restrictions translate to certain
+ responsibilities for you if you distribute copies of the software,
+ or if you modify it.
+
+ For example, if you distribute copies of such a program,
+ whether gratis or for a fee, you must give the recipients all the
+ rights that you have. You must make sure that they, too, receive
+ or can get the source code. And you must show them these terms so
+ they know their rights.
+
+ We protect your rights with two steps:
+
+
+
+ copyright the software, and
+
+
+ offer you this license which gives you legal
+ permission to copy, distribute and/or modify the
+ software.
+
+
+
+
+ Also, for each author's protection and ours, we want to make
+ certain that everyone understands that there is no warranty for
+ this free software. If the software is modified by someone else
+ and passed on, we want its recipients to know that what they have
+ is not the original, so that any problems introduced by others
+ will not reflect on the original authors' reputations.
+
+ Finally, any free program is threatened constantly by
+ software patents. We wish to avoid the danger that redistributors
+ of a free program will individually obtain patent licenses, in
+ effect making the program proprietary. To prevent this, we have
+ made it clear that any patent must be licensed for everyone's free
+ use or not licensed at all.
+
+ The precise terms and conditions for copying, distribution
+ and modification follow.
+
+
+
+
+
+ Terms and Conditions for Copying, Distribution and Modification
+
+
+
+ Section 1
+
+ You may copy and distribute verbatim copies of the
+ Program's source code as you receive it, in any medium,
+ provided that you conspicuously and appropriately publish on
+ each copy an appropriate copyright notice and disclaimer of
+ warranty; keep intact all the notices that refer to this
+ License and to the absence of any warranty; and give any other
+ recipients of the Program a copy of this License along with
+ the Program.
+
+ You may charge a fee for the physical act of
+ transferring a copy, and you may at your option offer warranty
+ protection in exchange for a fee.
+
+
+
+
+
+ Section 2
+
+ You may modify your copy or copies of the Program or
+ any portion of it, thus forming a work based on the
+ Program, and copy and distribute such modifications or
+ work under the terms of above, provided that you also meet all of these
+ conditions:
+
+
+
+ You must cause the modified files to carry prominent
+ notices stating that you changed the files and the date of
+ any change.
+
+
+ You must cause any work that you distribute or
+ publish, that in whole or in part contains or is derived
+ from the Program or any part thereof, to be licensed as a
+ whole at no charge to all third parties under the terms of
+ this License.
+
+
+ If the modified program normally reads commands
+ interactively when run, you must cause it, when started
+ running for such interactive use in the most ordinary way,
+ to print or display an announcement including an
+ appropriate copyright notice and a notice that there is no
+ warranty (or else, saying that you provide a warranty) and
+ that users may redistribute the program under these
+ conditions, and telling the user how to view a copy of
+ this License.
+
+
+ Exception
+
+ If the Program itself is interactive but does not
+ normally print such an announcement, your work based
+ on the Program is not required to print an
+ announcement.
+
+
+
+
+
+
+ These requirements apply to the modified work as a whole.
+ If identifiable sections of that work are not derived from the
+ Program, and can be reasonably considered independent and separate
+ works in themselves, then this License, and its terms, do not
+ apply to those sections when you distribute them as separate
+ works. But when you distribute the same sections as part of a
+ whole which is a work based on the Program, the distribution of
+ the whole must be on the terms of this License, whose permissions
+ for other licensees extend to the entire whole, and thus to each
+ and every part regardless of who wrote it.
+
+ Thus, it is not the intent of this section to claim rights
+ or contest your rights to work written entirely by you; rather,
+ the intent is to exercise the right to control the distribution of
+ derivative or collective works based on the Program.
+
+ In addition, mere aggregation of another work not based on
+ the Program with the Program (or with a work based on the Program)
+ on a volume of a storage or distribution medium does not bring the
+ other work under the scope of this License.
+
+
+
+
+
+ Section 3
+
+ You may copy and distribute the Program (or a work
+ based on it, under ) in
+ object code or executable form under the terms of and above provided that you also
+ do one of the following:
+
+
+
+
+ Accompany it with the complete corresponding
+ machine-readable source code, which must be distributed
+ under the terms of and
+ above on a medium
+ customarily used for software interchange; or,
+
+
+
+
+ Accompany it with a written offer, valid for at
+ least three years, to give any third party, for a charge
+ no more than your cost of physically performing source
+ distribution, a complete machine-readable copy of the
+ corresponding source code, to be distributed under the
+ terms of and above on a medium
+ customarily used for software interchange; or,
+
+ Accompany it with the information you received as
+ to the offer to distribute corresponding source code.
+ (This alternative is allowed only for noncommercial
+ distribution and only if you received the program in
+ object code or executable form with such an offer, in
+ accord with Subsection b above.)
+
+
+
+
+
+ The source code for a work means the preferred form of the
+ work for making modifications to it. For an executable work,
+ complete source code means all the source code for all modules it
+ contains, plus any associated interface definition files, plus the
+ scripts used to control compilation and installation of the
+ executable. However, as a special exception, the source code
+ distributed need not include anything that is normally distributed
+ (in either source or binary form) with the major components
+ (compiler, kernel, and so on) of the operating system on which the
+ executable runs, unless that component itself accompanies the
+ executable.
+
+ If distribution of executable or object code is made by
+ offering access to copy from a designated place, then offering
+ equivalent access to copy the source code from the same place
+ counts as distribution of the source code, even though third
+ parties are not compelled to copy the source along with the object
+ code.
+
+
+
+
+
+ Section 4
+
+ You may not copy, modify, sublicense, or distribute the
+ Program except as expressly provided under this License. Any
+ attempt otherwise to copy, modify, sublicense or distribute the
+ Program is void, and will automatically terminate your rights
+ under this License. However, parties who have received copies, or
+ rights, from you under this License will not have their licenses
+ terminated so long as such parties remain in full
+ compliance.
+
+
+
+
+
+ Section 5
+
+ You are not required to accept this License, since you have
+ not signed it. However, nothing else grants you permission to
+ modify or distribute the Program or its derivative works. These
+ actions are prohibited by law if you do not accept this License.
+ Therefore, by modifying or distributing the Program (or any work
+ based on the Program), you indicate your acceptance of this
+ License to do so, and all its terms and conditions for copying,
+ distributing or modifying the Program or works based on it.
+
+
+
+
+
+ Section 6
+
+ Each time you redistribute the Program (or any work based on
+ the Program), the recipient automatically receives a license from
+ the original licensor to copy, distribute or modify the Program
+ subject to these terms and conditions. You may not impose any
+ further restrictions on the recipients' exercise of the rights
+ granted herein. You are not responsible for enforcing compliance
+ by third parties to this License.
+
+
+
+
+
+ Section 7
+
+ If, as a consequence of a court judgment or allegation of
+ patent infringement or for any other reason (not limited to patent
+ issues), conditions are imposed on you (whether by court order,
+ agreement or otherwise) that contradict the conditions of this
+ License, they do not excuse you from the conditions of this
+ License. If you cannot distribute so as to satisfy simultaneously
+ your obligations under this License and any other pertinent
+ obligations, then as a consequence you may not distribute the
+ Program at all. For example, if a patent license would not permit
+ royalty-free redistribution of the Program by all those who
+ receive copies directly or indirectly through you, then the only
+ way you could satisfy both it and this License would be to refrain
+ entirely from distribution of the Program.
+
+ If any portion of this section is held invalid or
+ unenforceable under any particular circumstance, the balance of
+ the section is intended to apply and the section as a whole is
+ intended to apply in other circumstances.
+
+ It is not the purpose of this section to induce you to
+ infringe any patents or other property right claims or to contest
+ validity of any such claims; this section has the sole purpose of
+ protecting the integrity of the free software distribution system,
+ which is implemented by public license practices. Many people
+ have made generous contributions to the wide range of software
+ distributed through that system in reliance on consistent
+ application of that system; it is up to the author/donor to decide
+ if he or she is willing to distribute software through any other
+ system and a licensee cannot impose that choice.
+
+ This section is intended to make thoroughly clear what is
+ believed to be a consequence of the rest of this License.
+
+
+
+
+
+ Section 8
+
+ If the distribution and/or use of the Program is restricted
+ in certain countries either by patents or by copyrighted
+ interfaces, the original copyright holder who places the Program
+ under this License may add an explicit geographical distribution
+ limitation excluding those countries, so that distribution is
+ permitted only in or among countries not thus excluded. In such
+ case, this License incorporates the limitation as if written in
+ the body of this License.
+
+
+
+
+
+ Section 9
+
+ The Free Software Foundation may publish revised and/or new
+ versions of the General Public License from time to time. Such
+ new versions will be similar in spirit to the present version, but
+ may differ in detail to address new problems or concerns.
+
+ Each version is given a distinguishing version number. If
+ the Program specifies a version number of this License which
+ applies to it and any later version
, you have the
+ option of following the terms and conditions either of that
+ version or of any later version published by the Free Software
+ Foundation. If the Program does not specify a version number of
+ this License, you may choose any version ever published by the
+ Free Software Foundation.
+
+
+
+
+
+ Section 10
+
+ If you wish to incorporate parts of the Program into other
+ free programs whose distribution conditions are different, write
+ to the author to ask for permission. For software which is
+ copyrighted by the Free Software Foundation, write to the Free
+ Software Foundation; we sometimes make exceptions for this. Our
+ decision will be guided by the two goals of preserving the free
+ status of all derivatives of our free software and of promoting
+ the sharing and reuse of software generally.
+
+
+
+
+
+ NO WARRANTY
+ Section 11
+
+ BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
+ WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
+ LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+ HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS
WITHOUT
+ WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
+ NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
+ QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+ PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
+ SERVICING, REPAIR OR CORRECTION.
+
+
+
+
+
+ Section 12
+
+ IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO
+ IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
+ MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
+ LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
+ INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
+ INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+ DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
+ OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
+ OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+ End of Terms and Conditions.
+
+
+
+
+
+
+
+ How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of
+ the greatest possible use to the public, the best way to
+ achieve this is to make it free software which everyone can
+ redistribute and change under these terms.
+
+ To do so, attach the following notices to the program.
+ It is safest to attach them to the start of each source file
+ to most effectively convey the exclusion of warranty; and each
+ file should have at least the copyright
line
+ and a pointer to where the full notice is found.
+
+
+ <one line to give the program's name and a brief idea of what it does.>
+ Copyright (C) 19yy <name of author>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+
+ Also add information on how to contact you by electronic
+ and paper mail.
+
+ If the program is interactive, make it output a short
+ notice like this when it starts in an interactive mode:
+
+
+ Gnomovision version 69, Copyright (C) 19yy name of author
+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+
+ The hypothetical commands `show w' and `show c' should
+ show the appropriate parts of the General Public License. Of
+ course, the commands you use may be called something other
+ than `show w' and `show c'; they could even be mouse-clicks or
+ menu items–whatever suits your program.
+
+ You should also get your employer (if you work as a
+ programmer) or your school, if any, to sign a copyright
+ disclaimer
for the program, if necessary. Here is a
+ sample; alter the names:
+
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+ <signature of Ty Coon>, 1 April 1989
+ Ty Coon, President of Vice
+
+
+ This General Public License does not permit
+ incorporating your program into proprietary programs. If your
+ program is a subroutine library, you may consider it more
+ useful to permit linking proprietary applications with the
+ library. If this is what you want to do, use the GNU Library
+ General Public License instead of this License.
+
+
+
+
diff --git a/Manuals/RepoUserguide/repository.docbook b/Manuals/RepoUserguide/repository.docbook
new file mode 100644
index 0000000..b9373cc
--- /dev/null
+++ b/Manuals/RepoUserguide/repository.docbook
@@ -0,0 +1,87 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+ The CentOS Artwork Repository Manual
+
+
+
+ Alain
+ Reguera Delgado
+
+
+
+
+
+ 2009
+ 2010
+ 2011
+ The CentOS Artwork SIG
+
+
+
+
+ Permission is granted to copy, distribute and/or modify
+ this document under the terms of the GNU Free
+ Documentation License, Version 1.2 or any later version
+ published by the Free Software Foundation; with no
+ Invariant Sections, no Front-Cover Texts, and no
+ Back-Cover Texts. A copy of the license is included in
+ the section entitled .
+
+
+
+ Jun, 2011
+
+
+
+ This manuals documents relevant information regarding
+ the deployment, organization, and administration of
+ CentOS Artwork Repository.
+
+
+
+
+
+
+ Repository
+ &intro;
+ &dir;
+
+
+
+ Licenses
+ &licenses-gpl;
+ &licenses-gfdl;
+
+
+
diff --git a/Manuals/Repository/repository-parts/Directories.docbook b/Manuals/Repository/repository-parts/Directories.docbook
deleted file mode 100644
index d3bb0bc..0000000
--- a/Manuals/Repository/repository-parts/Directories.docbook
+++ /dev/null
@@ -1,22 +0,0 @@
-
-
- Directories
-
- The CentOS Artwork Repository uses directories to organize
- files and describe conceptual idea about corporate identity. Such
- conceptual ideas are explained in each directory related
- documentation entry.
-
- In this chapter you'll learn what each directory inside The
- CentOS Artwork Repository is for and so, how you can make use of
- them. For that purpose, the following list of directories is
- available for you to explore:
-
- &dir-trunk;
- &dir-trunk-identity;
- &dir-trunk-identity-models;
- &dir-trunk-identity-models-themes;
- &dir-trunk-identity-models-themes-default;
- &dir-trunk-manuals;
-
-
diff --git a/Manuals/Repository/repository-parts/Directories/trunk.docbook b/Manuals/Repository/repository-parts/Directories/trunk.docbook
deleted file mode 100644
index 1847e6c..0000000
--- a/Manuals/Repository/repository-parts/Directories/trunk.docbook
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
- trunk
-
- The trunk directory
- structure implements the Subversion's trunk concept in a trunk,
- branches, tags repository structure. The trunk directory structure provides
- the main development line inside the CentOS Artwork
- Repository.
-
-
diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity.docbook
deleted file mode 100644
index b2ad8a1..0000000
--- a/Manuals/Repository/repository-parts/Directories/trunk/Identity.docbook
+++ /dev/null
@@ -1,210 +0,0 @@
-
-
- trunk/Identity
-
- The trunk/Identity
- directory implements The CentOS Project corporate
- identity based on the The CentOS Project
- mission and release
- schema.
-
- The CentOS Project exists to provide The CentOS
- Distribution. Additionally, The CentOS Project provides The
- CentOS Web and The CentOS Showroom to support and promote the
- existence of The CentOS Distribution, respectively.
-
- The
- CentOS Project corporate identity is the ``persona'' of the
- organization known as The CentOS Project. The CentOS Project
- corporate identity plays a significant role in the way The CentOS
- Project, as organization, presents itself to both internal and
- external stakeholders. In general terms, The CentOS Project
- corporate identity expresses the values and ambitions of The
- CentOS Project organization, its business, and its
- characteristics. The CentOS Project corporate identity provides
- visibility, recognizability, reputation, structure and
- identification to The CentOS Project organization by means of
- corporate design, corporate
- communication, and corporate
- behaviour.
-
- The
- corporate design is focused on the effective communication of
- corporate messages. Corporate messages are all the information
- emitted from the corporation to a target audience. In order for
- such communication to happen, it is required to put the messages
- on a medium available for the target audience to react upon.
- These media are know as corporate
- manifestations, because the corporation manifests its
- existence through them. The specific way used by the corporation
- to set their messages on different media is what the corporate
- design is about.
-
- The amount of manifestations a corporation uses to
- communicate its existence may very from one corporation to
- another. In the very specific case of The CentOS Project, the
- following corporate manifestations come to mind:
-
-
-
-
- The CentOS Distribution — This corporate
- manifestaion is built from SRPM packages. There are SRPM
- packages that make a remarkable use of images (e.g., Anaconda,
- Grub, Syslinux, Gdm, Kdm, Gsplash, Ksplash, Rhgb, Firstboot,
- etc.), packages that make a moderate use of images and
- packages that don't use images at all. Also, there are some
- packages that make use of text-based information that need to
- be changed, too (e.g., release notes, eula, the welcome page
- of the web browser, etc.), in order for The CentOS Project to
- comply the redistribution guidelines of its upstream provider.
- The CentOS Distribution corporate manifestation focuses its
- attention on SRPM packages that use images in a remarkable
- way, specifically those packages that contain branding
- information, in both image and textual format, from the
- upstream provider. This way, replacing image and text-based
- files, we implement the corporate design of The CentOS
- Distribution corporate manifestations.
-
-
-
-
- The CentOS Web — This corporate manifestation
- exists to support The CentOS Distribution corporate
- manifestation. The CentOS Web corporate manifestation covers
- web applications used by The CentOS Project to manifest its
- existence on the Internet. These web applications are free
- software and come from different providers which distribute
- their work with predefined visual styles. Frequently, these
- predefined visual styles have no visual relation among
- themselves and introduce some visual contraditions when they
- all are put together. These visual contraditions need to be
- removed in order to comply with The CentOS Project corporate
- structure guidelines.
-
-
-
-
- The CentOS Showroom — This corporate manifestation
- exists to promote The CentOS Distribution. The CentOS
- Showroom corporate manifestation covers industrial production
- of objects branded by The CentOS Project (e.g., clothes,
- stationery and installation media). These branded objects are
- for distribution on social events and/or shops. They provide
- a way of promotion and a route for commercialization that may
- help to aliviate The CentOS Project expenses (e.g., hosting,
- servers, full-time-developers, etc.), in a similar way as
- donations may do.
-
-
-
-
- The corporate manifestations above seem to cover all the
- media required by The CentOS Project, as organization, to show its
- existence. However, other corporate manifestations could be added
- in the future, if needed, to cover different areas like building,
- offices, transportation and whaterver medium The CentOS Project
- thouches to show its existence.
-
- The CentOS Project corporate communication is
- based on community communication and takes
- place through the following avenues:
-
-
- The CentOS Chat (#centos, #centos-social},
- #centos-devel on irc.freenode.net)
- The CentOS Mailing Lists ().
- The CentOS Forums ().
- The CentOS Wiki ().
- Social events, interviews, conferences, etc.
-
-
-
-
- The CentOS Project corporate behaviour is based on
- community behaviour which take place in .
-
- The CentOS Project corporate structure is based on a
- monolithic corporate visual identity
- structure. In this configuration, one unique name and
- one unique visual style is used in all corporate manifestations of
- The CentOS Project.
-
- In a monolithic corporate visual identity structure,
- internal and external stakeholders feel a strong sensation of
- uniformity, orientation, and identification with the organization.
- No matter if you are visiting web sites, using the distribution,
- or acting on social events, the one unique name and one unique
- visual style connects them all to say: Hey! we are all
- part of The CentOS Project.
-
- Other corporate structures for The CentOS Project have been
- considered as well. Such is the case of producing one different
- visual style for each major release of The CentOS Distribution.
- This structure isn't inconvenient at all, but some visual
- contradictions could be introduced if it isn't applied correctly
- and we need to be aware of it. To apply it correctly, we need to
- know what The CentOS Project is made of.
-
- The CentOS Project, as organization, is mainly made of (but
- not limited to) three corporate manifestions: The CentOS
- Distribution, The CentOS Web and The CentOS Showroom. Inside The
- CentOS Distribution corporate manifestations, The CentOS Project
- maintains near to four different major releases of The CentOS
- Distribution (e.g., the operating system), parallely in time.
- However, inside The CentOS Web visual manifestations, the content
- is produced for no specific release information (e.g., there is no
- a complete web site for each major release of The CentOS
- Distribution individually, but one web site to cover them all).
- Likewise, the content produced in The CentOS Showroom is created
- for no release-specific at all, but for The CentOS Project in
- general.
-
- In order to produce the correct corporate structure for The
- CentOS Project, we need to concider all the corporate
- manifestations The CentOS Project is made of, not just one of
- them. If one different visual style is used for each major
- release of The CentOS Distribution, which one of those different
- visual styles would be used to cover the remaining visual
- manifestations The CentOS Project is made of (e.g., The CentOS Web
- and The CentOS Showroom)?
-
- Probably you are thinking, that's right, but The CentOS
- Brand connects them all already, why would we need to join them up
- into the same visual style too, isn't it more work to do, and
- harder to maintain?
-
- Harder to maintain, more work to do, probably. Specially
- when you consider that The CentOS Project has proven stability and
- consistency through time and, that, certainly, didn't come through
- swinging magical wands or something but hardly working out to
- automate tasks and providing maintainance through time. Said that,
- we consider that The CentOS Project corporate structure must be
- consequent with such stability and consistency tradition, beyond
- the work it might require initially. It is true that The CentOS
- Brand does connect all the visual manifestations it is present on,
- but that connection would be stronger if one unique visual style
- backups it, too. In fact, whatever thing you do to strength the
- visual connection among The CentOS Project corporate
- manifestations would be very good in favor of The CentOS Project
- recognition.
-
- Obviously, having just one visual style in all corporate
- manifestations for eternity would be a very boring thing and would
- give the impression of a visually dead project. So, there is no
- problem on creating a brand new visual style for each new major
- release of The CentOS Distribution, in order to refresh The CentOS
- Distribution visual style; the problem itself is in not
- propagating the brand new visual style created for the new release
- of The CentOS Distribution to all other visual manifestations The
- CentOS Project is made of, in a way The CentOS Project could be
- recognized no matter what corporate manifestation be in front of
- us. Such lack of uniformity is what introduces the visual
- contradition we are precisely trying to solve by mean of themes
- production in the CentOS Artwork Repository.
-
-
diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models.docbook
deleted file mode 100644
index fba2893..0000000
--- a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models.docbook
+++ /dev/null
@@ -1,4 +0,0 @@
-
- trunk/Identity/Models
- ...
-
diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes.docbook
deleted file mode 100644
index a2660e4..0000000
--- a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes.docbook
+++ /dev/null
@@ -1,31 +0,0 @@
-
-
- trunk/Identity/Models/Themes
-
- This directory implements the concept of themes'
- design models.
-
- Themes' design models provide the structural part of images
- (e.g., dimensions, translation markers, position of each element
- on the visible area, etc.) required by
- centos-art.sh to perform theme rendition. The
- provide the modeling characteristics for all the different visual
- manifestations a theme is made of. Using themes' design models
- reduce the time needed for propagating an artistic motif to
- different visual manifestations.
-
- In this directory, themes' design models are organized by
- name. There is one directory for each theme's design model. Each
- design model directory must be named as specified in . Inside themes' design models
- directories, there is one directory for each visual manifestions a
- theme is made of. These directories are named visual
- manifestation directories and contain one or more SVG
- files to describe the visual structure of that visual
- manifestion.
-
- Themes' design models are SVG files and
- can be localized using the locale
functionality of
- centos-art.sh script.
-
-
diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook
deleted file mode 100644
index 30fe79b..0000000
--- a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook
+++ /dev/null
@@ -1,16 +0,0 @@
-
-
- trunk/Identity/Models/Themes/Default
-
- This directory implements the concept of themes'
- default design models.
-
- Themes' default design models provide the common structural
- information (e.g., image dimensions, translation markers,
- trademark position, etc.) the centos-art.sh
- script uses to produce images when no other design model is
- specified through the option at
- rendition time.
-
-
diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Manuals.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Manuals.docbook
deleted file mode 100644
index f089182..0000000
--- a/Manuals/Repository/repository-parts/Directories/trunk/Manuals.docbook
+++ /dev/null
@@ -1,4 +0,0 @@
-
- trunk/Manuals
- ...
-
diff --git a/Manuals/Repository/repository-parts/Introduction.docbook b/Manuals/Repository/repository-parts/Introduction.docbook
deleted file mode 100644
index c0a4d95..0000000
--- a/Manuals/Repository/repository-parts/Introduction.docbook
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
- Introduction
-
- Welcome to The CentOS Artwork Repository
- Manual.
-
- The CentOS Artwork Repository Manual describes how The
- CentOS Project corporate visual identity is organized and produced
- inside the CentOS Artwork Repository (). If you are
- looking for a comprehensive, task-oriented guide for understanding
- how The CentOS Project corporate visual identity is produced, this
- is the manual for you.
-
- This guide assumes you have a basic understanding of The
- CentOS Distribution. If you need help with CentOS, refer to the
- help page on The CentOS Wiki () for a list of different
- places you can find help.
-
- &intro-history;
- &intro-copying;
- &intro-usage;
-
-
diff --git a/Manuals/Repository/repository-parts/Introduction/copying.docbook b/Manuals/Repository/repository-parts/Introduction/copying.docbook
deleted file mode 100644
index 1c679e0..0000000
--- a/Manuals/Repository/repository-parts/Introduction/copying.docbook
+++ /dev/null
@@ -1,91 +0,0 @@
-
-
- Copying conditions
-
- Copyright © 2009, 2010, 2011 The CentOS Project
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-
-
- Preamble
-
- The CentOS Artwork Repository organizes files in a very
- specific way to implement The CentOS Project corporate visual
- identity. This very specific organization of files must be
- considered part of centos-art.sh script, a bash
- script that automate most of the frequent tasks inside the
- repository.
-
- The centos-art.sh script and the
- organization of files it needs to work are not in the public
- domain; they are copyrighted and there are restrictions on their
- distribution, but these restrictions are designed to permit
- everything that a good cooperating citizen would want to do. What
- is not allowed is to try to prevent others from further sharing
- any version of this program that they might get from you.
-
- Specifically, we want to make sure that you have the right
- to give away copies of centos-art.sh script and
- the organization of files it needs to work, that you receive
- source code or else can get it if you want it, that you can change
- this program or use pieces of it in new free programs, and that
- you know you can do these things.
-
- To make sure that everyone has such rights, we have to
- forbid you to deprive anyone else of these rights. For example,
- if you distribute copies of the centos-art.sh
- script, you must give the recipients all the rights that you have.
- You must make sure that they, too, receive or can get the source
- code. And you must tell them their rights.
-
- Also, for our own protection, we must make certain that
- everyone finds out that there is no warranty for the
- centos-art.sh script. If this program is
- modified by someone else and passed on, we want their recipients
- to know that what they have is not what we distributed, so that
- any problems introduced by others will not reflect on our
- reputation.
-
- The centos-art.sh script is released as a
- GPL work. Individual packages used by
- centos-art.sh script include their own licenses
- and the centos-art.sh script license applies to
- all packages that it does not clash with. If there is a clash
- between the centos-art.sh script license and
- individual package licenses, the individual package license
- applies instead.
-
- The precise conditions of the license for the
- centos-art.sh script are found in the . This manual specifically is
- covered by the .
-
-
-
-
- The CentOS Brand
-
- The CentOS Brand () is the main visual manifestaion of The
- CentOS Project. The CentOS Project uses The CentOS Brand to
- connect all its visual manifestions (e.g., GNU/Linux
- Distributions, Websites, Stationery, etc.) and, this way, it
- provides recognition among other similar projects available on the
- Internet.
-
- Both The CentOS Brand and all the visual manifestations that
- derivate from it are available for you to study and propose
- improvement around a good citizen's will at The CentOS Community
- environment, but you are not allowed to redistribute them
- elsewhere, without the given permission of The CentOS
- Project.
-
- If you need to redistribute either The CentOS Brand or any
- visual manifestation derived from it, write your intentions to the
- The CentOS Developers mailing list
- (centos-devel@centos.org).
-
-
-
-
-
diff --git a/Manuals/Repository/repository-parts/Introduction/document-convenctions.docbook b/Manuals/Repository/repository-parts/Introduction/document-convenctions.docbook
deleted file mode 100644
index 8e12a51..0000000
--- a/Manuals/Repository/repository-parts/Introduction/document-convenctions.docbook
+++ /dev/null
@@ -1,147 +0,0 @@
-
-
- Document convenctions
-
- In this manual the personal pronoun we
- is used to repesent The CentOS Artwork SIG,
- the group of persons that build The CentOS Project corporate
- visual identity through the CentOS Artwork Repository.
-
- In this manual, certain words are represented in different
- fonts, typefaces, sizes, and weights. This highlighting is
- systematic; different words are represented in the same style to
- indicate their inclusion in a specific category. The types of
- words that are represented this way include the following:
-
-
-
- command
-
- Linux commands (and other operating system
- commands, when used) are represented this way. This
- style should indicate to you that you can type the
- word or phrase on the command line and press Enter to
- invoke a command. Sometimes a command contains words
- that would be displayed in a different style on their
- own (such as file names). In these cases, they are
- considered to be part of the command, so the entire
- phrase is displayed as a command. For example:
-
- Use the centos-art identity
- --render='path/to/dir' command to produce
- contents inside the trunk/Identity directory
- structure.
-
-
-
-
-
- file name
-
- File names, directory names, paths, and RPM
- package names are represented this way. This style
- indicates that a particular file or directory exists
- with that name on your system. Examples:
-
- The init.sh file in
- trunk/Scripts/Bash/Cli/
- directory is the initialization script, written in
- Bash, used to automate most of tasks in the
- repository.
-
- The centos-art command uses
- the ImageMagick RPM package to
- convert images from PNG format to other
- formats.
-
-
-
-
-
- key
-
- A key on the keyboard is shown in this style.
- For example:
-
- To use TAB completion to list
- particular files in a directory, type @command{ls},
- then a character, and finally the Tab key. Your
- terminal displays the list of files in the working
- directory that begin with that character.
-
-
-
-
- key-combination
-
- A combination of keystrokes is represented in
- this way. For example:
-
- The CtrlAltBackspace
- key combination exits your graphical session and
- returns you to the graphical login screen or the
- console.
-
-
-
-
-
-
- computer output
-
- Text in this style indicates text displayed to a
- shell prompt such as error messages and responses to
- commands. For example:
-
- The ls command displays the
- contents of a directory. For example:
-
-
-Config help_renameEntry.sh
-help_copyEntry.sh help_restoreCrossReferences.sh
-help_deleteCrossReferences.sh help_searchIndex.sh
-
-
- The output returned in response to the command (in this
- case, the contents of the directory) is shown in this
- style.
-
-
-
-
- Additionally, we use several different strategies to draw
- your attention to certain pieces of information. In order of
- urgency, these items are marked as a note, tip, important,
- caution, or warning. For example:
-
-
- Remember that Linux is case sensitive. In other words, a
- rose is not a ROSE is not a rOsE.
-
-
-
- The directory @file{/usr/share/doc/} contains additional
- documentation for packages installed on your system.
-
-
-
- If you modify the DHCP configuration file, the changes
- do not take effect until you restart the DHCP daemon.
-
-
-
- Do not perform routine tasks as root — use a
- regular user account unless you need to use the root account
- for system administration tasks.
-
-
-
- Be careful to remove only the necessary partitions.
- Removing other partitions could result in data loss or a
- corrupted system environment.
-
-
-
diff --git a/Manuals/Repository/repository-parts/Introduction/history.docbook b/Manuals/Repository/repository-parts/Introduction/history.docbook
deleted file mode 100644
index 8d75b67..0000000
--- a/Manuals/Repository/repository-parts/Introduction/history.docbook
+++ /dev/null
@@ -1,148 +0,0 @@
-
-
- History
-
- The CentOS Artwork Repository started around 2008 during a
- discussion about how to automate the slide images of Anaconda, at
- CentOS Developers mailing list (centos-devel@centos.org). In such
- discussion, Ralph Angenendt rose up his hand to ask —Do you have
- something to show?—.
-
- To answer the question, I suggested a bash script which
- combined SVG and SED files in order to produce PNG images in
- different languages —together with the proposition of
- creating a Subversion repository where translations and image
- production could be distributed inside The CentOS
- Community—.
-
- Karanbirn Sighn considered the idea intresting and provided
- the infrastructure necessary to support the effort. This way the
- CentOS Artwork SIG (https://projects.centos.org/trac/artwork/) and
- the CentOS Artwork Repository
- (https://projects.centos.org/svn/artwork/) were officially
- created.
-
- Once the CentOS Artwork Repository was available, I uploaded
- the bash script for rendering Anaconda slides; Ralph Angenendt
- documented it very well; and people started to download working
- copies of CentOS Artwork Repository to produce slide images in
- their own languages.
-
- Around 2009, the rendition script was at a very rustic state
- where only slide images could be produced, so it was redesigned to
- extend the image production to other areas, different from slide
- images. In this configuration, one SVG file was used as input to
- produce a translated instance of it which, in turn, was used to
- produce one translated PNG image as output. The SVG translated
- instance was created through SED replacement commands. The
- translated PNG image was created from the SVG translated instance
- using Inkscape command-line interface.
-
- The repository directory structure was prepared to receive
- the rendition script using design templates and translation files
- in the same location. There was one directory structure for each
- artwork that needed to be produced. In this configuration, if you
- would want to produce the same artwork with a different visual
- style or structure, it was needed to create a new directory
- structure for it because both the image structure and the image
- visual style were together in the design template.
-
- The rendition script was moved to a common place and linked
- from different directory structures. There was no need to have the
- same code in different directory structures if it could be in just
- one place and then be linked from different locations.
-
- The concepts about corporate identity began to be
- considered. As referece, it was used the book Corporate
- Identity
by Wally Olins (1989) and Wikipedia related links
- (e.g., ). This way, the rendition script main's goal becomes to:
- automate production of a monolithic corporate visual identity
- structure, based on the mission and the release schema of The
- CentOS Project.
-
- The repository directory structures began to be documented
- inside by mean of flat text files. Later, documentation in flat
- text files was moved onto LaTeX format and this way The
- CentOS Artwork Repository Manual
is initiated.
-
- Around 2010, the rendition script changed its name from
- render.sh to centos-art.sh
- and became a collection of functionalities where rendition was
- just one among others (e.g., documenting and localizing).
-
- The centos-art.sh was initialy conceived
- to organize automation of most frequent tasks inside the
- repository based in the conceptual idea of Unix toolbox:
- create small and specialized tools that do one thing
- well. This way, functionalities inside
- centos-art.sh were identified and separated one
- another. For example, when images were rendered, there was no need
- to load functionalities related to documentation manual. This
- layout moved us onto common functionalities and specific
- functionalities inside centos-art.sh script.
- Common functionalities are loaded when
- centos-art.sh script is initiated and are
- available to specific functionalities.
-
- There was no need to have links all around the
- repository if a command-line interface could be created (through
- symbolic links, in the ~/bin directory) and be called
- anywhere inside the repository as it would be a regular
- command.
-
- The centos-art.sh script was redesigned
- to handle command-line options trough getopt
- option parser.
-
- The repository directory structure was updated to improve
- the implementation of concepts related to corporate visual
- identity. Specially in the area related to themes which were
- divided into design models and
- artistic motifs to eliminate the content
- duplication produced by having both image structure and image
- visual style in the same file. Now, both
- centos-art.sh and repository directory
- structure are able to produce themes as result of arbitrary
- combinations between design models (structures) and artistic
- motifs (visual styles).
-
- In the documentation area, the documentation files in LaTeX
- format were migrated to Texinfo format. In this configuration,
- each directory structure in the repository has a documentation
- entry associated in a Texinfo structure which can be read, edited
- and administered (e.g., renamed, deleted, copied) interactively
- throuch centos-art.sh. Additionally, the
- texi2html program was used to produced XHTML
- output customized by CSS from The CentOS Webenv.
-
- Around 2011, the centos-art.sh script was
- redesigned to start translating SVG and other XML-based files
- (e.g., XHTML and Docbook files) through the
- xml2po program and shell scripts files (e.g.,
- Bash scripts) through GNU gettext tools. This
- configuration provided a stronger interface for graphic designers,
- translators and programmers to produce localized content. The SED
- files are no longer used to handle translations.
-
- The render
, help
and
- locale
functionalities were consolidated as the most
- frequent tasks performed inside the repository. Additionally, the
- prepare
and tuneup
functionalities are
- maintained as useful tasks.
-
- The centos-art.sh script is updated to
- organize functionalities in two groups: the administrative
- functionalities
and the productive
- functionalities
. The administrative functionalities cover
- actions like: copying, deleting and renaming directory structures
- inside the repository. Also, preparing your workstation for using
- centos-art.sh script, making backups of the
- distribution theme currently installed, installing themes created
- inside repository and restoring themes from backup. On the other
- hand, the productive functionalities cover actions like: content
- rendition, content localization, content documentation and content
- maintainance.
-
-
diff --git a/Manuals/Repository/repository-parts/Introduction/send-in-your-feedback.docbook b/Manuals/Repository/repository-parts/Introduction/send-in-your-feedback.docbook
deleted file mode 100644
index 198696e..0000000
--- a/Manuals/Repository/repository-parts/Introduction/send-in-your-feedback.docbook
+++ /dev/null
@@ -1,17 +0,0 @@
-
-
- Send in your feedback
-
- If you find an error in the CentOS Artwork
- Repository, or if you have thought of a way to make
- this manual better, we would like to hear from you! Share your
- suggestions in the appropriate mailing list
- (http://lists.centos.org/) and/or bug tracker
- (http://bugs.centos.org/).
-
- When you make suggestion, try to be as specific as possible.
- For example, if you have found an error in the manual, include the
- section number and some of the surrounding text so we can find it
- easily.
-
-
diff --git a/Manuals/Repository/repository-parts/Introduction/usage.docbook b/Manuals/Repository/repository-parts/Introduction/usage.docbook
deleted file mode 100644
index 235972f..0000000
--- a/Manuals/Repository/repository-parts/Introduction/usage.docbook
+++ /dev/null
@@ -1,369 +0,0 @@
-
-
- Usage convenctions
-
- The CentOS Artwork Repository is supported by Subversion
- (http://subversion.tigris.org/), a version control system which
- allows you to keep old versions of files and directories (usually
- source code), keep a log of who, when, and why changes occurred,
- etc., like CVS, RCS or SCCS.
-
- When using Subversion there is one "source repository" and
- many "working copies" of that source repository. The working
- copies are independent one another, can be distributed all around
- the world and provide a local place for designers, documentors,
- translators and programmers to perform their work in a
- descentralized way. The source repository, on the other hand,
- provides a central place for all independent working copies to
- interchange data and provides the information required to permit
- extracting previous versions of files at any time.
-
-
-
- Policy
-
- The CentOS Artwork Repository is a collaborative tool
- that anyone can have access to. However, changing that tool in
- any form is something that should be requested in the CentOS
- Developers mailing list (centos-devel@centos.org). Generally,
- people download working copies from CentOS Artwork Repository,
- study the repository organization, make some changes in their
- working copies, make some tests to verify such changes do work
- the way expected and finally request access to commit them up
- to the CentOS Artwork Repository (i.e., the source repository)
- for others to benefit from them.
-
- Once you've received access to commit your changes,
- there is no need for you to request permission again to commit
- other changes from your working copy to CentOS Artwork
- Repository as long as you behave as a good
- cooperating citizen. Otherwise, your rights to
- commit changes might be temporarly revoked or permanently
- banished.
-
- As a good cooperating citizen one understand of a person
- who respects the work already done by others and share ideas
- with authors before changing relevant parts of their work,
- specially in situations when the access required to realize
- the changes has been granted already. Of course, there is a
- time when conversation has taken place, the paths has been
- traced and changing the work is so obvious that there is no
- need for you to talk about it; that's because you already did,
- you already built the trust to keep going. Anyway, the mailing
- list mentioned above is available for sharing ideas in a way
- that good relationship between community citizens could be
- constantly balanced.
-
- The relationship between community citizens is monitored
- by repository administrators. Repository administrators are
- responsible of granting that everything goes the way it needs
- to go in order for the CentOS Artwork Repository to accomplish
- its mission which is: to provide a colaborative tool for The
- CentOS Community where The CentOS Project corporate visual
- identity is built and maintained by The CentOS Community
- itself.
-
- It is also important to remember that all the program
- and documentation source files inside CentOS Artwork
- Repository must comply the terms of and
- respectively in order for them to remain inside the
- repository.
-
-
-
-
-
- Work lines
-
- Content production inside the repository is organized by
- work lines. There are three major work
- lines of production inside The CentOS Artwork Repository,
- which are: Graphic design,
- Documentation and
- Localization. The specific way of
- producing content inside each specific work line is
- standardized by mean of centos-art.sh
- script (which in turn, can be considered a work line by itself
- [e.g., the Automation work line]). The
- centos-art.sh script provides one specific
- functionality for automating each major work line of content
- production (e.g., render
for producing images,
- help
for manage documentation, and
- locale
for localizing contents).
-
- The graphic design work line exists to cover brand
- design, typography design and themes design mainly.
- Additionally, some auxiliar areas like icon design,
- illustration design, brushes design, patterns designs and
- palettes of colors are also included here for completeness.
- The graphic design work line is organized in the trunk/Identity directory.
-
- The documentation work line exists to describe what each
- directory inside the CentOS Artwork Repository is for, the
- conceptual ideas behind them and, if possible, how automation
- scripts make use of them. The documentation work line is
- organized in the trunk/Manuals directory.
-
- The localization work line exists to provide the
- translation messages required to produce content in different
- languages. Translation messages inside the repository are
- stored as portable objects (e.g., .po, .pot) and machine
- objects (.mo). The localization work line is organized in the
- trunk/Locales
- directory.
-
- The automation work line exists to standardize content
- production inside the working copies of CentOS Artwork
- Repository. Here is developed the
- centos-art.sh script, a bash script
- specially designed to automate most frequent tasks (e.g.,
- rendition, documentation and localization) inside the
- repository. There is no need to type several tasks, time
- after time, if they can be programmed into just one executable
- script. The automation work line is organized in the
- trunk/Scripts
- directory.
-
-
-
-
-
- Relation between directories
-
- In order for automation scripts to produce content inside a
- working copy of CentOS Artwork Repository, it is required that all
- work lines be related somehow. The relation is used by automation
- scripts to know where to retrive the information they need to work
- with (e.g., design model, translation messages, output locations,
- etc.). This kind of relation is built using two path
- constructions named master paths and
- auxiliar paths.
-
- The master path points only to directories that contain
- source files (e.g., SVG files) required to produce output base
- content (e.g., PNG files) through automation scripts. Each master
- path inside the repository may have several auxiliar paths
- associated, but auxiliar paths can only have one master path
- associated.
-
- Master paths used for producing images through SVG rendition
- are organized under trunk/Identity/Models directory
- structure and the auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory
- structures.
-
- Auxiliar paths can point either to directories or files.
- When an auxiliar path points to a directory, that directory
- contains information that modifies somehow the content produced
- from master paths (e.g., translation messages) or provides the
- output information required to know where the content produced
- from the master path should be stored. When an auxiliar path
- points to a file, that file has no other purpose but to document
- the master path it refers to.
-
- Auxiliar paths should never be modified under any reason but
- to satisfy the relationship with the master path. Liberal change
- of auxiliar paths may suppress the conceptual idea they were
- initially created for; and certainly, automation scripts may stop
- working as expected.
-
- The relationship between auxiliar paths and master paths is
- built by combining the master path and the second level directory
- structures of the repository. The master path is considered the
- path identifier and the repository second level directory
- structure is considered the common part of the path where the path
- identifier is appended to. So, if we have the master path
- trunk/Identity/Models/Brands, we'll
- end up having, at least, the trunk/Identity/Images/Brands auxiliar
- path for storing output files and, optionally, one path under
- trunk/Manuals for storing
- documentation and one path under trunk/Locales for storing
- localizations.
-
-
-
-
-
- Syncronizing paths
-
- Once both master paths and their auxiliar paths have been
- set, they shouldn't be changed. Assuming one master path must be
- changed it is required that all related auxiliar paths be changed,
- too. This is required in order for master paths to retain their
- relation with auxiliar paths. This process of keeping relation
- between master paths and auxiliar paths is known as path
- syncronization.
-
- Path syncronization is required for automation scripts to
- know where to store final output, where to retrive translation
- messages, documentation, and any information that might be
- desired. If the relation between master paths and auxiliar paths
- is lost, there is no way for centos-art.sh
- script to know where to retrive the information it needs to work
- with. Path syncronization is the way we use to organize and
- extend the information stored in the repository.
-
- Path syncronization may imply both movement of files and
- replacement of content inside files. Movement of files is related
- to actions like renaming files and directories inside the
- repository. Replacement of content inside files is related to
- actions like replacing information (e.g., paths information)
- inside files in order to keep file contents and file locations
- consistent one another.
-
- The order followed to syncronize path information is very
- important because the versioned nature of the repository files we
- are working with. When a renaming action must be performed, we
- avoid making replacements inside files first and file movements
- later. This would require two commit actions: one for the files'
- internal changes and another for the file movement itself.
- Otherwise, we prefer to perform file movements first and file
- internal replacements later. This way it is possible to commit
- both changes as if they were just one.
-
- There is no support for URLs actions inside
- centos-art.sh script. The
- centos-art.sh script is designed to work with
- local files inside the working copy only. If you need to perform
- URL actions directly, use Subversion commands
- instead.
-
- At this moment there is no full implementation of path
- syncronization process inside centos-art.sh
- script except by texinfo
backend of
- help
functionality which provides a restricted
- implementation of path syncronization to this specific area of
- documentation through the ,
- and options.
- The plan for a full implementation of path syncronization would be
- to create individual restricted implementations like this one for
- other areas that demand it and then, create a higher implmentation
- that combines all restricted implementations as needed. This way,
- if we try to rename a repository directory the higer action will
- define which are all the restricted actions that should be
- performed in order for make a full path syncronization. For
- example, if the directory we are renaming is part of graphic
- design work line, it is required to syncronize related paths in
- documentation and localization work lines. Likewise, if the
- directory we are renaming is in documentation work line, it is
- required to syncronize related paths in graphic design and
- localization work lines. In all these cases, the direction used
- for syncronizing paths must be from master path to auxiliar path
- and never the opposite (i.e., rename the master path first and
- auxiliar paths later).
-
- A practical example, through which you can notice the
- usefulness of path syncronization process, is what happen when
- documentation entries are renamed (see section ...).
-
-
-
-
-
- Extending repository organization
-
- Occasionly, you may find that new components of The
- CentOS Project corporate visual identity need to be added to
- the repository in order to work them out. If that is the case,
- the first question we need to ask ourselves, before start to
- create directories blindly all over, is: What is the
- right place to store it?
-
- The best place to find answers is in The CentOS
- Community (see page http://wiki.centos.org/Help), but going
- there with hands empty is not good idea. It may give the
- impression you don't really care about. Instead, consider the
- following suggestions to find your own comprehension in order
- to make your own propositions based on it.
-
- When extending respository structure it is very useful
- to bear in mind The CentOS Project corporate visual identity
- structure, The CentOS Mission and The CentOS Release Schema.
- The rest is a matter of choosing appropriate names. It is also
- worth to know that each directory in the repository responds
- to a conceptual idea that justifies its existence.
-
- To build a directory structure inside the repository,
- you need to define the conceptual idea first and later create
- the directory, remembering that there are locations inside the
- repository that define conceptual ideas you probably would
- prefer to reuse. For example, the trunk/Identity/Images/Themes
- directory stores theme artistic motifs, the trunk/Identity/Models/Themes
- directory stores theme design models, the trunk/Manuals directory stores
- documentation files, the trunk/Locales stores translation
- messages, and the trunk/Scripts stores automation
- scripts.
-
- To better illustrate this desition process, you can
- consider to examin the trunk/Identity/Images/Themes/TreeFlower/3
- directory structure as example. This directory can be read
- as: the theme development line of version 3
of
- TreeFlower
artistic motif. Additional, we can
- say that TreeFlower
artistic motif is part of
- themes, as themes are part of The CentOS Project corporate
- visual identity.
-
- The relationship between conceptual ideas can be
- stablished by reading each repository documentation entry
- individually, from trunk directory to a deeper
- directory in the path. For reading repository documentation
- entries we use the help
functionality of
- centos-art.sh script.
-
-
-
-
-
- File names convenction
-
- Inside the CentOS Artwork Repository, generally, file
- names are all written in lowercase (e.g.,
- 01-welcome.png,
- splash.png,
- anaconda_header.png, etc.) and directory
- names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel
- case (e.g., TreeFlower,
- etc.).
-
- In the very specific case of repository documentation
- entries, file names follow the directory naming convenction.
- This is because they are documenting directories and that is
- something we want to remark. So, to better describe what we
- are documenting, documentation entries follow the name
- convenction used by the item they document.
-
-
-
-
-
- Repository layout
-
- The CentOS Artwork Repository is organized through a
- convenctional trunk
, branches
- and tags
layout. Explanation of each directory
- inside the repository can be found in the chapter.
-
-
-
-
diff --git a/Manuals/Repository/repository-parts/Licenses/gfdl.docbook b/Manuals/Repository/repository-parts/Licenses/gfdl.docbook
deleted file mode 100644
index 789bb53..0000000
--- a/Manuals/Repository/repository-parts/Licenses/gfdl.docbook
+++ /dev/null
@@ -1,591 +0,0 @@
-
-
- GNU Free Documentation License
-
- Version 1.2, November 2002
-
- Copyright © 2000, 2001, 2002 Free Software Foundation,
- Inc. 675 Mass Ave, Cambridge, MA 02139, USA
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-
-
- Preamble
-
- The purpose of this License is to make a manual,
- textbook, or other functional and useful document
- free
in the sense of freedom: to assure
- everyone the effective freedom to copy and redistribute it,
- with or without modifying it, either commercially or
- noncommercially. Secondarily, this License preserves for the
- author and publisher a way to get credit for their work, while
- not being considered responsible for modifications made by
- others.
-
- This License is a kind of copyleft
, which
- means that derivative works of the document must themselves be
- free in the same sense. It complements the , which is a copyleft license
- designed for free software.
-
- We have designed this License in order to use it for
- manuals for free software, because free software needs free
- documentation: a free program should come with manuals
- providing the same freedoms that the software does. But this
- License is not limited to software manuals; it can be used for
- any textual work, regardless of subject matter or whether it
- is published as a printed book. We recommend this License
- principally for works whose purpose is instruction or
- reference.
-
-
-
-
-
- Applicability and definitions
-
- This License applies to any manual or other work, in any
- medium, that contains a notice placed by the copyright holder
- saying it can be distributed under the terms of this License.
- Such a notice grants a world-wide, royalty-free license,
- unlimited in duration, to use that work under the conditions
- stated herein. The Document
, below, refers to
- any such manual or work. Any member of the public is a
- licensee, and is addressed as you
. You accept
- the license if you copy, modify or distribute the work in a
- way requiring permission under copyright law.
-
- A
- Modified Version
of the Document means any work
- containing the Document or a portion of it, either copied
- verbatim, or with modifications and/or translated into another
- language.
-
- A
- Secondary Section
is a named appendix or a
- front-matter section of the Document that deals exclusively
- with the relationship of the publishers or authors of the
- Document to the Document's overall subject (or to related
- matters) and contains nothing that could fall directly within
- that overall subject. (Thus, if the Document is in part a
- textbook of mathematics, a may not explain any mathematics.) The relationship could be
- a matter of historical connection with the subject or with
- related matters, or of legal, commercial, philosophical,
- ethical or political position regarding them.
-
- The Invariant Sections
are certain
- whose titles are
- designated, as being those of Invariant Sections, in the
- notice that says that the Document is released under this
- License. If a section does not fit the above definition of
- Secondary then it is not allowed to be designated as
- Invariant. The Document may contain zero Invariant Sections.
- If the Document does not identify any Invariant Section then
- there are none.
-
- The
- Cover Texts
are certain short passages of text
- that are listed, as Front-Cover Texts or Back-Cover Texts, in
- the notice that says that the Document is released under this
- License. A Front-Cover Text may be at most 5 words, and a
- Back-Cover Text may be at most 25 words.
-
- A
- Transparent
copy of the Document means a
- machine-readable copy, represented in a format whose
- specification is available to the general public, that is
- suitable for revising the document straightforwardly with
- generic text editors or (for images composed of pixels)
- generic paint programs or (for drawings) some widely available
- drawing editor, and that is suitable for input to text
- formatters or for automatic translation to a variety of
- formats suitable for input to text formatters. A copy made in
- an otherwise file format whose
- markup, or absence of markup, has been arranged to thwart or
- discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of
- text. A copy that is not
is called Opaque
.
-
- Examples of suitable formats for copies
- include plain ASCII without markup, Texinfo input format,
- LaTeX input format, SGML or XML using a publicly available
- DTD, and standard-conforming simple HTML, PostScript or PDF
- designed for human modification. Examples of transparent
- image formats include PNG, XCF and JPG. Opaque formats
- include proprietary formats that can be read and edited only
- by proprietary word processors, SGML or XML for which the DTD
- and/or processing tools are not generally available, and the
- machine-generated HTML, PostScript or PDF produced by some
- word processors for output purposes only.
-
- The Title
- Page
means, for a printed book, the title page itself,
- plus such following pages as are needed to hold, legibly, the
- material this License requires to appear in the title page.
- For works in formats which do not have any title page as such,
- Title Page
means the text near the most
- prominent appearance of the work's title, preceding the
- beginning of the body of the text.
-
- A section Entitled XYZ
means a named
- subunit of the Document whose title either is precisely XYZ or
- contains XYZ in parentheses following text that translates XYZ
- in another language. (Here XYZ stands for a specific section
- name mentioned below, such as Acknowledgements
,
- Dedications
, Endorsements
, or
- History
.) To Preserve the Title
- of such a section when you modify the Document means that it
- remains a section Entitled XYZ
according to
- this definition.
-
- The Document may include Warranty Disclaimers next to
- the notice which states that this License applies to the
- Document. These Warranty Disclaimers are considered to be
- included by reference in this License, but only as regards
- disclaiming warranties: any other implication that these
- Warranty Disclaimers may have is void and has no effect on the
- meaning of this License.
-
-
-
-
-
- Verbatim copying
-
- You may copy and distribute the Document in any medium,
- either commercially or noncommercially, provided that this
- License, the copyright notices, and the license notice saying
- this License applies to the Document are reproduced in all
- copies, and that you add no other conditions whatsoever to
- those of this License. You may not use technical measures to
- obstruct or control the reading or further copying of the
- copies you make or distribute. However, you may accept
- compensation in exchange for copies. If you distribute a
- large enough number of copies you must also follow the
- conditions in section .
-
- You may also lend copies, under the same conditions
- stated above, and you may publicly display copies.
-
-
-
-
-
- Copying in quantity
-
- If you publish printed copies (or copies in media that
- commonly have printed covers) of the Document, numbering more
- than 100, and the Document's license notice requires Cover
- Texts, you must enclose the copies in covers that carry,
- clearly and legibly, all these :
- Front-Cover Texts on the front cover, and Back-Cover Texts on
- the back cover. Both covers must also clearly and legibly
- identify you as the publisher of these copies. The front
- cover must present the full title with all words of the title
- equally prominent and visible. You may add other material on
- the covers in addition. Copying with changes limited to the
- covers, as long as they preserve the title of the Document and
- satisfy these conditions, can be treated as verbatim copying
- in other respects.
-
- If the required texts for either cover are too
- voluminous to fit legibly, you should put the first ones
- listed (as many as fit reasonably) on the actual cover, and
- continue the rest onto adjacent pages.
-
- If you publish or distribute Opaque copies of the
- Document numbering more than 100, you must either include a
- machine-readable copy along with each Opaque copy,
- or state in or with each Opaque copy a computer-network
- location from which the general network-using public has
- access to download using public-standard network protocols a
- complete copy of the Document, free of added
- material. If you use the latter option, you must take
- reasonably prudent steps, when you begin distribution of
- Opaque copies in quantity, to ensure that this
- copy will remain thus accessible at the stated location until
- at least one year after the last time you distribute an Opaque
- copy (directly or through your agents or retailers) of that
- edition to the public.
-
- It is requested, but not required, that you contact the
- authors of the Document well before redistributing any large
- number of copies, to give them a chance to provide you with an
- updated version of the Document.
-
-
-
-
-
- Modifications
-
- You may copy and distribute a of the Document under the
- conditions of sections and above,
- provided that you release the under precisely this License, with the filling the role of the
- Document, thus licensing distribution and modification of the
- to whoever possesses a
- copy of it. In addition, you must do these things in the
- :
-
-
-
-
- Use in the (and on
- the covers, if any) a title distinct from that of the
- Document, and from those of previous versions (which
- should, if there were any, be listed in the History
- section of the Document). You may use the same title
- as a previous version if the original publisher of
- that version gives permission.
-
-
- List on the , as
- authors, one or more persons or entities responsible
- for authorship of the modifications in the , together with at least
- five of the principal authors of the Document (all of
- its principal authors, if it has fewer than five),
- unless they release you from this requirement.
-
-
-
- State on the the
- name of the publisher of the , as the
- publisher.
-
-
-
- Preserve all the copyright notices of the
- Document.
-
-
-
- Add an appropriate copyright notice for your
- modifications adjacent to the other copyright
- notices.
-
-
-
- Include, immediately after the copyright
- notices, a license notice giving the public permission
- to use the under the terms of this
- License, in the form shown in the Addendum
- below.
-
-
-
- Preserve in that license notice the full lists
- of and required
- given in the Document's
- license notice.
-
-
-
- Include an unaltered copy of this License.
-
-
-
- Preserve the section Entitled
- History
, Preserve its Title, and add to
- it an item stating at least the title, year, new
- authors, and publisher of the as given on the . If there is no section
- Entitled History
in the Document, create
- one stating the title, year, authors, and publisher of
- the Document as given on its , then add an item describing the as stated in the previous
- sentence.
-
-
-
- Preserve the network location, if any, given in
- the Document for public access to a copy of the Document, and
- likewise the network locations given in the Document
- for previous versions it was based on. These may be
- placed in the History
section. You may
- omit a network location for a work that was published
- at least four years before the Document itself, or if
- the original publisher of the version it refers to
- gives permission.
-
-
-
- For any section Entitled
- Acknowledgements
or
- Dedications
, Preserve the Title of the
- section, and preserve in the section all the substance
- and tone of each of the contributor acknowledgements
- and/or dedications given therein.
-
-
-
- Preserve all the of the Document,
- unaltered in their text and in their titles. Section
- numbers or the equivalent are not considered part of
- the section titles.
-
-
-
- Delete any section Entitled
- Endorsements
. Such a section may not
- be included in the .
-
-
-
- Do not retitle any existing section to be
- Entitled Endorsements
or to conflict in
- title with any .
-
-
- Preserve any Warranty Disclaimers.
-
-
-
-
- If the includes new
- front-matter sections or appendices that qualify as and contain no material copied
- from the Document, you may at your option designate some or
- all of these sections as invariant. To do this, add their
- titles to the list of in the 's license notice. These titles
- must be distinct from any other section titles.
-
- You may add a section Entitled
- Endorsements
, provided it contains nothing but
- endorsements of your by various
- parties–for example, statements of peer review or that
- the text has been approved by an organization as the
- authoritative definition of a standard.
-
- You may add a passage of up to five words as a
- Front-Cover Text, and a passage of up to 25 words as a
- Back-Cover Text, to the end of the list of in the . Only one passage of
- Front-Cover Text and one of Back-Cover Text may be added by
- (or through arrangements made by) any one entity. If the
- Document already includes a cover text for the same cover,
- previously added by you or by arrangement made by the same
- entity you are acting on behalf of, you may not add another;
- but you may replace the old one, on explicit permission from
- the previous publisher that added the old one.
-
- The author(s) and publisher(s) of the Document do not by
- this License give permission to use their names for publicity
- for or to assert or imply endorsement of any .
-
-
-
-
-
- Combining documents
-
- You may combine the Document with other documents
- released under this License, under the terms defined in
- section above for
- modified versions, provided that you include in the
- combination all of the of
- all of the original documents, unmodified, and list them all
- as of your combined work
- in its license notice, and that you preserve all their
- Warranty Disclaimers.
-
- The combined work need only contain one copy of this
- License, and multiple identical may be replaced with a single
- copy. If there are multiple with the same name but
- different contents, make the title of each such section unique
- by adding at the end of it, in parentheses, the name of the
- original author or publisher of that section if known, or else
- a unique number. Make the same adjustment to the section
- titles in the list of in
- the license notice of the combined work.
-
- In the combination, you must combine any sections
- Entitled History
in the various original
- documents, forming one section Entitled
- History
; likewise combine any sections Entitled
- Acknowledgements
, and any sections Entitled
- Dedications
. You must delete all sections
- Entitled Endorsements
.
-
-
-
-
-
- Collection of documents
-
- You may make a collection consisting of the Document and
- other documents released under this License, and replace the
- individual copies of this License in the various documents
- with a single copy that is included in the collection,
- provided that you follow the rules of this License for
- verbatim copying of each of the documents in all other
- respects.
-
- You may extract a single document from such a
- collection, and distribute it individually under this License,
- provided you insert a copy of this License into the extracted
- document, and follow this License in all other respects
- regarding verbatim copying of that document.
-
-
-
-
-
- Aggregation with independent works
-
- A compilation of the Document or its derivatives with
- other separate and independent documents or works, in or on a
- volume of a storage or distribution medium, is called an
- aggregate
if the copyright resulting from the
- compilation is not used to limit the legal rights of the
- compilation's users beyond what the individual works permit.
- When the Document is included in an aggregate, this License
- does not apply to the other works in the aggregate which are
- not themselves derivative works of the Document.
-
- If the Cover Text requirement of section is applicable to these
- copies of the Document, then if the Document is less than one
- half of the entire aggregate, the Document's may be placed on covers that bracket
- the Document within the aggregate, or the electronic
- equivalent of covers if the Document is in electronic form.
- Otherwise they must appear on printed covers that bracket the
- whole aggregate.
-
-
-
-
-
- Translations
-
- Translation is considered a kind of modification, so you
- may distribute translations of the Document under the terms of
- section . Replacing
- with translations
- requires special permission from their copyright holders, but
- you may include translations of some or all in addition to the original
- versions of these . You
- may include a translation of this License, and all the license
- notices in the Document, and any Warranty Disclaimers,
- provided that you also include the original English version of
- this License and the original versions of those notices and
- disclaimers. In case of a disagreement between the
- translation and the original version of this License or a
- notice or disclaimer, the original version will
- prevail.
-
- If a section in the Document is Entitled
- Acknowledgements
, Dedications
,
- or History
, the requirement (section ) to Preserve its Title
- (section ) will
- typically require changing the actual title.
-
-
-
-
-
- Termination
-
- You may not copy, modify, sublicense, or distribute the
- Document except as expressly provided for under this License.
- Any other attempt to copy, modify, sublicense or distribute
- the Document is void, and will automatically terminate your
- rights under this License. However, parties who have received
- copies, or rights, from you under this License will not have
- their licenses terminated so long as such parties remain in
- full compliance.
-
-
-
-
-
- Future Revisions of this License
-
- The Free Software Foundation may publish new, revised
- versions of the GNU Free Documentation License from time to
- time. Such new versions will be similar in spirit to the
- present version, but may differ in detail to address new
- problems or concerns. See .
-
- Each version of the License is given a distinguishing
- version number. If the Document specifies that a particular
- numbered version of this License or any later
- version
applies to it, you have the option of
- following the terms and conditions either of that specified
- version or of any later version that has been published (not
- as a draft) by the Free Software Foundation. If the Document
- does not specify a version number of this License, you may
- choose any version ever published (not as a draft) by the Free
- Software Foundation.
-
-
-
-
-
- How to use this License for your documents
-
- To use this License in a document you have written,
- include a copy of the License in the document and put the
- following copyright and license notices just after the title
- page:
-
-
- Copyright (C) YEAR YOUR NAME.
-
- Permission is granted to copy, distribute and/or modify this
- document under the terms of the GNU Free Documentation License,
- Version 1.2 or any later version published by the Free Software
- Foundation; with no Invariant Sections, no Front-Cover Texts, and
- no Back-Cover Texts. A copy of the license is included in the
- section entitled GNU Free Documentation License
.
-
-
- If you have ,
- Front-Cover Texts and Back-Cover Texts, replace the
- with...Texts
. line with this:
-
-
- with the Invariant Sections being LIST THEIR TITLES, with the
- Front-Cover Texts being LIST, and with the Back-Cover Texts being
- LIST.
-
-
- If you have
- without , or some other
- combination of the three, merge those two alternatives to suit
- the situation.
-
- If your document contains nontrivial examples of program
- code, we recommend releasing these examples in parallel under
- your choice of free software license, such as the GNU General
- Public License, to permit their use in free software.
-
-
-
-
diff --git a/Manuals/Repository/repository-parts/Licenses/gpl.docbook b/Manuals/Repository/repository-parts/Licenses/gpl.docbook
deleted file mode 100644
index 3ddcafc..0000000
--- a/Manuals/Repository/repository-parts/Licenses/gpl.docbook
+++ /dev/null
@@ -1,485 +0,0 @@
-
-
- GNU General Public License
-
- Version 2, June 1991
-
- Copyright © 1989, 1991 Free Software Foundation, Inc.
- 675 Mass Ave, Cambridge, MA 02139, USA
-
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-
-
- Preamble
-
- The licenses for most software are designed to take away
- your freedom to share and change it. By contrast, the GNU General
- Public License is intended to guarantee your freedom to share and
- change free software–to make sure the software is free for
- all its users. This General Public License applies to most of the
- Free Software Foundation's software and to any other program whose
- authors commit to using it. (Some other Free Software Foundation
- software is covered by the GNU Library General Public License
- instead.) You can apply it to your programs, too.
-
- When we speak of free software, we are referring to freedom,
- not price. Our General Public Licenses are designed to make sure
- that you have the freedom to distribute copies of free software
- (and charge for this service if you wish), that you receive source
- code or can get it if you want it, that you can change the
- software or use pieces of it in new free programs; and that you
- know you can do these things.
-
- To protect your rights, we need to make restrictions that
- forbid anyone to deny you these rights or to ask you to surrender
- the rights. These restrictions translate to certain
- responsibilities for you if you distribute copies of the software,
- or if you modify it.
-
- For example, if you distribute copies of such a program,
- whether gratis or for a fee, you must give the recipients all the
- rights that you have. You must make sure that they, too, receive
- or can get the source code. And you must show them these terms so
- they know their rights.
-
- We protect your rights with two steps:
-
-
-
- copyright the software, and
-
-
- offer you this license which gives you legal
- permission to copy, distribute and/or modify the
- software.
-
-
-
-
- Also, for each author's protection and ours, we want to make
- certain that everyone understands that there is no warranty for
- this free software. If the software is modified by someone else
- and passed on, we want its recipients to know that what they have
- is not the original, so that any problems introduced by others
- will not reflect on the original authors' reputations.
-
- Finally, any free program is threatened constantly by
- software patents. We wish to avoid the danger that redistributors
- of a free program will individually obtain patent licenses, in
- effect making the program proprietary. To prevent this, we have
- made it clear that any patent must be licensed for everyone's free
- use or not licensed at all.
-
- The precise terms and conditions for copying, distribution
- and modification follow.
-
-
-
-
-
- Terms and Conditions for Copying, Distribution and Modification
-
-
-
- Section 1
-
- You may copy and distribute verbatim copies of the
- Program's source code as you receive it, in any medium,
- provided that you conspicuously and appropriately publish on
- each copy an appropriate copyright notice and disclaimer of
- warranty; keep intact all the notices that refer to this
- License and to the absence of any warranty; and give any other
- recipients of the Program a copy of this License along with
- the Program.
-
- You may charge a fee for the physical act of
- transferring a copy, and you may at your option offer warranty
- protection in exchange for a fee.
-
-
-
-
-
- Section 2
-
- You may modify your copy or copies of the Program or
- any portion of it, thus forming a work based on the
- Program, and copy and distribute such modifications or
- work under the terms of above, provided that you also meet all of these
- conditions:
-
-
-
- You must cause the modified files to carry prominent
- notices stating that you changed the files and the date of
- any change.
-
-
- You must cause any work that you distribute or
- publish, that in whole or in part contains or is derived
- from the Program or any part thereof, to be licensed as a
- whole at no charge to all third parties under the terms of
- this License.
-
-
- If the modified program normally reads commands
- interactively when run, you must cause it, when started
- running for such interactive use in the most ordinary way,
- to print or display an announcement including an
- appropriate copyright notice and a notice that there is no
- warranty (or else, saying that you provide a warranty) and
- that users may redistribute the program under these
- conditions, and telling the user how to view a copy of
- this License.
-
-
- Exception
-
- If the Program itself is interactive but does not
- normally print such an announcement, your work based
- on the Program is not required to print an
- announcement.
-
-
-
-
-
-
- These requirements apply to the modified work as a whole.
- If identifiable sections of that work are not derived from the
- Program, and can be reasonably considered independent and separate
- works in themselves, then this License, and its terms, do not
- apply to those sections when you distribute them as separate
- works. But when you distribute the same sections as part of a
- whole which is a work based on the Program, the distribution of
- the whole must be on the terms of this License, whose permissions
- for other licensees extend to the entire whole, and thus to each
- and every part regardless of who wrote it.
-
- Thus, it is not the intent of this section to claim rights
- or contest your rights to work written entirely by you; rather,
- the intent is to exercise the right to control the distribution of
- derivative or collective works based on the Program.
-
- In addition, mere aggregation of another work not based on
- the Program with the Program (or with a work based on the Program)
- on a volume of a storage or distribution medium does not bring the
- other work under the scope of this License.
-
-
-
-
-
- Section 3
-
- You may copy and distribute the Program (or a work
- based on it, under ) in
- object code or executable form under the terms of and above provided that you also
- do one of the following:
-
-
-
-
- Accompany it with the complete corresponding
- machine-readable source code, which must be distributed
- under the terms of and
- above on a medium
- customarily used for software interchange; or,
-
-
-
-
- Accompany it with a written offer, valid for at
- least three years, to give any third party, for a charge
- no more than your cost of physically performing source
- distribution, a complete machine-readable copy of the
- corresponding source code, to be distributed under the
- terms of and above on a medium
- customarily used for software interchange; or,
-
- Accompany it with the information you received as
- to the offer to distribute corresponding source code.
- (This alternative is allowed only for noncommercial
- distribution and only if you received the program in
- object code or executable form with such an offer, in
- accord with Subsection b above.)
-
-
-
-
-
- The source code for a work means the preferred form of the
- work for making modifications to it. For an executable work,
- complete source code means all the source code for all modules it
- contains, plus any associated interface definition files, plus the
- scripts used to control compilation and installation of the
- executable. However, as a special exception, the source code
- distributed need not include anything that is normally distributed
- (in either source or binary form) with the major components
- (compiler, kernel, and so on) of the operating system on which the
- executable runs, unless that component itself accompanies the
- executable.
-
- If distribution of executable or object code is made by
- offering access to copy from a designated place, then offering
- equivalent access to copy the source code from the same place
- counts as distribution of the source code, even though third
- parties are not compelled to copy the source along with the object
- code.
-
-
-
-
-
- Section 4
-
- You may not copy, modify, sublicense, or distribute the
- Program except as expressly provided under this License. Any
- attempt otherwise to copy, modify, sublicense or distribute the
- Program is void, and will automatically terminate your rights
- under this License. However, parties who have received copies, or
- rights, from you under this License will not have their licenses
- terminated so long as such parties remain in full
- compliance.
-
-
-
-
-
- Section 5
-
- You are not required to accept this License, since you have
- not signed it. However, nothing else grants you permission to
- modify or distribute the Program or its derivative works. These
- actions are prohibited by law if you do not accept this License.
- Therefore, by modifying or distributing the Program (or any work
- based on the Program), you indicate your acceptance of this
- License to do so, and all its terms and conditions for copying,
- distributing or modifying the Program or works based on it.
-
-
-
-
-
- Section 6
-
- Each time you redistribute the Program (or any work based on
- the Program), the recipient automatically receives a license from
- the original licensor to copy, distribute or modify the Program
- subject to these terms and conditions. You may not impose any
- further restrictions on the recipients' exercise of the rights
- granted herein. You are not responsible for enforcing compliance
- by third parties to this License.
-
-
-
-
-
- Section 7
-
- If, as a consequence of a court judgment or allegation of
- patent infringement or for any other reason (not limited to patent
- issues), conditions are imposed on you (whether by court order,
- agreement or otherwise) that contradict the conditions of this
- License, they do not excuse you from the conditions of this
- License. If you cannot distribute so as to satisfy simultaneously
- your obligations under this License and any other pertinent
- obligations, then as a consequence you may not distribute the
- Program at all. For example, if a patent license would not permit
- royalty-free redistribution of the Program by all those who
- receive copies directly or indirectly through you, then the only
- way you could satisfy both it and this License would be to refrain
- entirely from distribution of the Program.
-
- If any portion of this section is held invalid or
- unenforceable under any particular circumstance, the balance of
- the section is intended to apply and the section as a whole is
- intended to apply in other circumstances.
-
- It is not the purpose of this section to induce you to
- infringe any patents or other property right claims or to contest
- validity of any such claims; this section has the sole purpose of
- protecting the integrity of the free software distribution system,
- which is implemented by public license practices. Many people
- have made generous contributions to the wide range of software
- distributed through that system in reliance on consistent
- application of that system; it is up to the author/donor to decide
- if he or she is willing to distribute software through any other
- system and a licensee cannot impose that choice.
-
- This section is intended to make thoroughly clear what is
- believed to be a consequence of the rest of this License.
-
-
-
-
-
- Section 8
-
- If the distribution and/or use of the Program is restricted
- in certain countries either by patents or by copyrighted
- interfaces, the original copyright holder who places the Program
- under this License may add an explicit geographical distribution
- limitation excluding those countries, so that distribution is
- permitted only in or among countries not thus excluded. In such
- case, this License incorporates the limitation as if written in
- the body of this License.
-
-
-
-
-
- Section 9
-
- The Free Software Foundation may publish revised and/or new
- versions of the General Public License from time to time. Such
- new versions will be similar in spirit to the present version, but
- may differ in detail to address new problems or concerns.
-
- Each version is given a distinguishing version number. If
- the Program specifies a version number of this License which
- applies to it and any later version
, you have the
- option of following the terms and conditions either of that
- version or of any later version published by the Free Software
- Foundation. If the Program does not specify a version number of
- this License, you may choose any version ever published by the
- Free Software Foundation.
-
-
-
-
-
- Section 10
-
- If you wish to incorporate parts of the Program into other
- free programs whose distribution conditions are different, write
- to the author to ask for permission. For software which is
- copyrighted by the Free Software Foundation, write to the Free
- Software Foundation; we sometimes make exceptions for this. Our
- decision will be guided by the two goals of preserving the free
- status of all derivatives of our free software and of promoting
- the sharing and reuse of software generally.
-
-
-
-
-
- NO WARRANTY
- Section 11
-
- BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
- WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
- LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
- HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS
WITHOUT
- WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
- NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
- FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
- QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
- PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
- SERVICING, REPAIR OR CORRECTION.
-
-
-
-
-
- Section 12
-
- IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO
- IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
- MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
- LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
- INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
- INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
- DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
- OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
- OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
- ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
- End of Terms and Conditions.
-
-
-
-
-
-
-
- How to Apply These Terms to Your New Programs
-
- If you develop a new program, and you want it to be of
- the greatest possible use to the public, the best way to
- achieve this is to make it free software which everyone can
- redistribute and change under these terms.
-
- To do so, attach the following notices to the program.
- It is safest to attach them to the start of each source file
- to most effectively convey the exclusion of warranty; and each
- file should have at least the copyright
line
- and a pointer to where the full notice is found.
-
-
- <one line to give the program's name and a brief idea of what it does.>
- Copyright (C) 19yy <name of author>
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-
- Also add information on how to contact you by electronic
- and paper mail.
-
- If the program is interactive, make it output a short
- notice like this when it starts in an interactive mode:
-
-
- Gnomovision version 69, Copyright (C) 19yy name of author
- Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
- This is free software, and you are welcome to redistribute it
- under certain conditions; type `show c' for details.
-
-
- The hypothetical commands `show w' and `show c' should
- show the appropriate parts of the General Public License. Of
- course, the commands you use may be called something other
- than `show w' and `show c'; they could even be mouse-clicks or
- menu items–whatever suits your program.
-
- You should also get your employer (if you work as a
- programmer) or your school, if any, to sign a copyright
- disclaimer
for the program, if necessary. Here is a
- sample; alter the names:
-
-
- Yoyodyne, Inc., hereby disclaims all copyright interest in the program
- `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
- <signature of Ty Coon>, 1 April 1989
- Ty Coon, President of Vice
-
-
- This General Public License does not permit
- incorporating your program into proprietary programs. If your
- program is a subroutine library, you may consider it more
- useful to permit linking proprietary applications with the
- library. If this is what you want to do, use the GNU Library
- General Public License instead of this License.
-
-
-
-
diff --git a/Manuals/Repository/repository.docbook b/Manuals/Repository/repository.docbook
deleted file mode 100644
index b9373cc..0000000
--- a/Manuals/Repository/repository.docbook
+++ /dev/null
@@ -1,87 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-]>
-
-
-
-
-
- The CentOS Artwork Repository Manual
-
-
-
- Alain
- Reguera Delgado
-
-
-
-
-
- 2009
- 2010
- 2011
- The CentOS Artwork SIG
-
-
-
-
- Permission is granted to copy, distribute and/or modify
- this document under the terms of the GNU Free
- Documentation License, Version 1.2 or any later version
- published by the Free Software Foundation; with no
- Invariant Sections, no Front-Cover Texts, and no
- Back-Cover Texts. A copy of the license is included in
- the section entitled .
-
-
-
- Jun, 2011
-
-
-
- This manuals documents relevant information regarding
- the deployment, organization, and administration of
- CentOS Artwork Repository.
-
-
-
-
-
-
- Repository
- &intro;
- &dir;
-
-
-
- Licenses
- &licenses-gpl;
- &licenses-gfdl;
-
-
-