<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE TIP SYSTEM "http://www.tcl.tk/cgi-bin/tct/tip/tipxml.dtd">
<!-- Converted at Mon May 20 13:45:01 GMT 2013 -->
<!-- TIP AutoGenerator - written by Donal K. Fellows -->

<TIP number='78'>
<header><title>TEA 2.0 Definitions</title><author address="mailto:andreas_kupries@users.sourceforge.net">Andreas Kupries</author><author address="mailto:lvirden@yahoo.com">Larry W. Virden</author><status type='informative' state='draft' vote='prior'>$Revision: 1.4 $</status><history></history><created day='15' month='dec' year='2001' /></header>
<abstract>This document is an informational TIP providing definitions for commonly used terms (like package, extension, core, distribution, etc.) to make future communication among people in the community easier. It is recommended that future and past documents specifying details inside of the greater context of TEA refer to this document to ensure a consistent usage of terms.</abstract>
<body><section title="Background">
<para>This document is an adjunct to the [TIP &lt;&lt;vision&gt;&gt;]. <emph style="italic">(DKF - Is this meant to be a reference to <tipref type="text" tip="34"/>? Edit to such if so...)</emph></para>
<para>To facilitate the specification and adoption of clearly defined interfaces to various activities and technologies it specifies a number of terms used by the community at large to create a greater unity and coherence in the usage of these terms. In other words, by creating generally accepted definitions for important terms the risk of misunderstanding each other is reduced.</para>
</section>
<section title="Specification of Technical Terms">
<para>This section specifies a number of important technical terms in alphabetical order. Terms used inside of a specification are highlighted.</para>
<itemize><item.i><para>Application</para><para>An entity implementing some functionality required by a <emph style="italic">P/A User</emph> (see section <emph style="italic">Roles</emph>) to perform his work. Consists of one more files. May make use of <emph style="italic">packages</emph> to implement its functionality.</para></item.i><item.i><para>Archive</para><para>Encapsulation of a <emph style="italic">distribution</emph> in a single file. Well-known formats for archives are tar, gzipped tar, bzipped tar, and zip.</para></item.i><item.i><para>Binary generation</para><para>The process of wrapping up a built package into a binary <emph style="italic">distribution</emph>. See <emph style="italic">building</emph> too.</para></item.i><item.i><para>Building</para><para>The process of <emph style="italic">configuring</emph> and <emph style="italic">transforming</emph> a source <emph style="italic">distribution</emph> into a set of files which can be either immediately installed on the site which built them or wrapped into a binary <emph style="italic">distribution</emph> for shipment to other sites. This also includes the execution of a test-suite coming with the package.</para></item.i><item.i><para>Bundle</para><para>A <emph style="italic">distribution</emph> encapsulating more than one <emph style="italic">package</emph>.</para></item.i><item.i><para>Catalog</para><para>A catalog is a site providing an index of the packages.</para></item.i><item.i><para>Configuration</para><para>The process of customizing a source distribution for a particular architecture and/or site. A part of <emph style="italic">Building</emph>.</para></item.i><item.i><para>Conflict</para><para>Two or more packages are said to be in conflict if the usage of one of them excludes the usage of the others.</para><para>In a <emph style="italic">strong conflict</emph> installing one of the packages disallows even the installation of the others.</para></item.i><item.i><para>Core</para><para>A shorthand for <emph style="italic">Tcl core</emph>.</para></item.i><item.i><para>Core distribution.</para><para>See <emph style="italic">Tcl core distribution</emph>.</para></item.i><item.i><para>Dependency</para><para>A relationship between packages. A package X is said dependent on another package Y if said package Y is required to allow X to work.</para><para>There are several types of dependencies:</para><itemize><item.i><para>Build-time dependency</para><para>Y is required to allow X to be build.</para></item.i><item.i><para>Run-time dependency</para><para>Y is required to allow the usage of an installed X.</para></item.i><item.i><para>Optional dependency</para><para>Y can be used by X (usually for improved performance) but is not required for building or use.</para></item.i></itemize></item.i><item.i><para>Distribution</para><para>An encapsulation of one or more <emph style="italic">packages</emph> for transport between places, machines, organizations, and people. Several types of distributions are possible, explained below.</para><enumerate><item.e index='1'><para>binary</para><para>A binary distribution is in a state and format allowing the installation of the contained packages on a particular platform.</para><para>It contains at least all the files</para><itemize><item.i><para>implementing the functionality of the distributed packages and</para></item.i><item.i><para>required to allow the package management of the Tcl core to handle the packages.</para><para>A binary distribution usually contains just the files for a single architecture. This is not a explicit requirement however. In other words, a binary distribution is allowed to contain the files for several architectures. Such a binary distribution will be called a <emph style="italic">fat binary distribution</emph>.</para><para>We distinguish between three sub-types:</para></item.i><item.i><para>installable</para><para>This is the minimal binary distribution we spoke of before.</para></item.i><item.i><para>auto-installable</para><para>Like <emph style="italic">installable</emph>&apos;, but additionally contains an application whose execution will perform all the steps which are necessary to install the contained packages at a site. The installation to add the packages to (and thus the location of the installed packages) can be freely chosen by the caller of the executable.</para></item.i><item.i><para>auto-image</para><para>Like <emph style="italic">auto-installable</emph>, but the final location of the packages is hard-wired into the distribution. This means that a site using auto-images is restricted to one installation per architecture for which files are contained in the binary distribution.</para><para>Some of the existing archive formats restrict their contained distributions to this type. Examples of such archive formats are</para><itemize><item.i><para>RPM (RedHat Package Manager)</para></item.i><item.i><para>DEB (DEBian Linux package format)</para></item.i></itemize><para>See [TIP 55] for the specification of a proposed layout for binary distributions.</para></item.i></itemize></item.e><item.e index='2'><para>bundle</para><para>A distribution which either contains the distributions of more than one package or a list of references to packages. The references are done by specifying the name and version of the packages contained in the bundle.</para></item.e><item.e index='3'><para>buildable</para><para>See <emph style="italic">source</emph>.</para></item.e><item.e index='4'><para>compileable</para><para>See <emph style="italic">source</emph>.</para></item.e><item.e index='5'><para>raw</para><para>A raw distribution is the most fundamental distribution. Its format is nearly completely unspecified. Its contents are straight from a source repository. The process of converting a raw distribution into a source distribution is called <emph style="italic">Preparation</emph>.</para><para>Because of the unformatted nature of a raw distribution the commands for its conversion into a source distribution have to be part of it. This is the only part of a raw distribution which can and has to be specified.</para><describe><item.d name='Example'><para>The execution of <emph style="italic">autoconf</emph> to generate a <emph style="italic">configure</emph> script from its <emph style="italic">configure.in</emph> file can be a single step in a complex preparation.</para></item.d></describe></item.e><item.e index='6'><para>source</para><para>A source distribution is in a format and state where tools can be used to build its contents.</para><para>The format needs further specification but for now we can assume that it is governed by the current TEA specification.</para><para>Alternate name for this type of distribution are <emph style="italic">compileable</emph> and <emph style="italic">buildable</emph>.</para></item.e></enumerate></item.i><item.i><para>Distribution repository</para><para>See <emph style="italic">repository</emph></para></item.i><item.i><para>Extension</para><para>Alternate name for a <emph style="italic">package</emph>, generally used for packages requiring compilation to become functional.</para><para>This term is <emph style="italic">deprecated</emph>.</para></item.i><item.i><para>Installation</para><para>A special type of <emph style="italic">distribution repository, binary</emph> (see <emph style="italic">repository</emph>) containing all <emph style="italic">packages</emph> which were installed on a site. A site may host several installations differing in version and/or configuration of Tcl, and/or the platform Tcl was built for, etc.</para><para>Currently difficult to do but in the future it should made be possible for an installation to refer and use another installation, provided both are configured identically. This allows a site to build a hierarchy of installations from the most general containing the common packages down to installations associated with one or more <emph style="italic">P/A Developers</emph>.</para></item.i><item.i><para>Installing</para><para>The process of unpacking a binary distribution and adding the contained packages to an <emph style="italic">installation</emph>. The latter may include moving files to their proper places.</para><para>Also the process of adding a built package to an <emph style="italic">installation</emph>.</para></item.i><item.i><para>Manifest</para><para>A file detailing the files making up a particular package.</para></item.i><item.i><para>Package</para><para>A collection of files providing additional functionality to a user of a Tcl interpreter when loaded into said interpreter.</para><para>Some files in a package implement the provided functionality whereas other files contain meta-information required by the package management of Tcl to be able to use the package.</para></item.i><item.i><para>Preparation</para><para>The process of converting a raw <emph style="italic">distribution</emph> into a source <emph style="italic">distribution</emph> suitable as input to <emph style="italic">building</emph>. This includes actions like:</para><itemize><item.i><para>Retrieval of sources from a source repository</para></item.i><item.i><para>Creating a <emph style="italic">configure</emph> file from its <emph style="italic">configure.in</emph>.</para></item.i><item.i><para>Creating the distributed documentation from internal sources.</para></item.i><item.i><para>Removal of internal files containing notes, scratch info and the like.</para></item.i><item.i><para>Inserting version information into files.</para></item.i><item.i><para>...</para><para>The tool <emph style="italic">makedist</emph> (which I wrote) is in my mind when thinking about this step.</para></item.i></itemize></item.i><item.i><para>Raw retrieval</para><para>The process of retrieving a raw <emph style="italic">distribution</emph> from a <emph style="italic">source repository</emph>.</para></item.i><item.i><para>Repository</para><para>General term with two possible meanings.</para><enumerate><item.e index='1'><para>A collection of <emph style="italic">archives</emph>. The exact term for this type of repository is &quot;distribution repository&quot;.</para><para>If a distribution repository is restricted to one type of distributions this type can be added to the term as further specification of the type of repository. Thus</para><itemize><item.i><para><emph style="italic">distribution repository, binary</emph>, or</para></item.i><item.i><para><emph style="italic">distribution repository, source</emph>.</para></item.i></itemize></item.e><item.e index='2'><para>A collection of directories, developer files and control files containing version control information. The exact term for this type of repository is <emph style="italic">source repository</emph>.</para><para>A repository can either be internal to an organization or public.</para></item.e></enumerate></item.i><item.i><para>Source repository</para><para>See <emph style="italic">repository</emph></para></item.i><item.i><para>Tcl core</para><para>The most fundamental part in the Tcl world; the interpreter engine and the builtin commands coming with it. These are all commands and procedures reported by <emph style="italic">info commands</emph> for a <emph style="italic">tclsh</emph> which was started with an empty <emph style="italic">.tclshrc</emph> file and after sourcing all <emph style="italic">.tcl</emph> files in the directory returned by <emph style="italic">info library</emph>.</para></item.i><item.i><para>Tcl core distribution</para><para>The most fundamental distribution there is. Contains the <emph style="italic">Tcl core</emph> and a number of packages.</para></item.i></itemize>
</section>
<section title="Roles">
<para>The terms in the preceding section specified both passive data structures and actions upon them. This section specifies the possible actors, i.e. entities which perform one or more of these actions.</para>
<para>To make the specification easier, related actions are grouped into roles of behavior. The mapping from roles to actual actors, i.e. people and organizations is n:m. On other words, one actor may have several roles, either at once or changing over time and one role can be held by several distinct actors.</para>
<para>Examples are given at the end of this section.</para>
<enumerate><item.e index='1'><para>Catalog manager</para><para>A catalog manager handles one or more catalogs. He is responsible for</para><itemize><item.i><para>the final name arbitration for packages with conflicting names</para></item.i><item.i><para>and the categorization of the packages indexed by the catalog.</para></item.i></itemize></item.e><item.e index='2'><para>P/A Builder</para><para>A package and/or application builder is a person and/or organization</para><itemize><item.i><para>who retrieves raw distributions from source repositories and (in a sequence of several steps) generates binary distributions from them.</para></item.i><item.i><para>or who retrieves source distributions from distribution repositories and (in a sequence of several steps) generates binary distributions from them.</para></item.i><item.i><para>uploads the generated binary distributions into one or more distribution repositories.</para></item.i><item.i><para>uploads the generated source distributions into one or more distribution repositories.</para><para>The intermediate steps performed by a builder are <emph style="italic">Preparation</emph>, <emph style="italic">Building</emph>, and <emph style="italic">Binary generation</emph>.</para><para>If <emph style="italic">System administrator</emph> and <emph style="italic">P/A Builder</emph> coordinate with each other it is also possible to install a package directly from the built package.</para><para><emph style="italic">NOTE:</emph> Think about splitting P/A Builder into two roles; one for the preparation of source <emph style="italic">distributions</emph> and a second role for the generation of binary <emph style="italic">distributions</emph>.</para><verbatim><vline encoding='base64'>ICAgICAgICAgVE9ETyBGaW5kIHNvbWUgbmljZSBuYW1lcyBmb3IgdGhlIHNwbGl0IHJvbGVzLg==</vline></verbatim></item.i></itemize></item.e><item.e index='3'><para>P/A Developer</para><para>A developer is a <emph style="italic">P/A User</emph> whose tasks include the creation of new packages and/or applications. A workspace contains the raw sources of these new packages and applications. For posterity and version control it is kept synchronized with one or more <emph style="italic">source repositories</emph>.</para><para>During development, at least one installation has to be accessible, containing the initial packages, the new packages and the applications built upon the packages.</para></item.e><item.e index='4'><para>P/A User</para><para>A person or organization which uses Tcl based tools but does not develop new code. Its workspace contains the files required for the tasks at hand.</para><para>The border between the roles of P/A Developer and P/A User blurs if the tool being used allows one to customize/program/extend it in Tcl.</para></item.e><item.e index='5'><para>Repository manager</para><para>This role handles the management of all types of <emph style="italic">repositories</emph>. This role is not part of the development process <emph style="italic">per se</emph> and has no direct actions for with regards to distributions, packages, sources, etc.</para><para>Repository managers are responsible for keeping the system up and running, doing adequate backups, supporting mirrors, providing browsing and download capabilities, providing confidence that updates to items in the repository are being done by the approved person or persons, etc.</para><para>The role is related to <emph style="italic">System administrator</emph>, but not the same. It was split out of that role because a <emph style="italic">System-Administrator</emph> is usually internal to an organization whereas a repository and its management can be provided by an entity external to the organization.</para></item.e><item.e index='6'><para>System administrator</para><para>A system administrator manages</para><itemize><item.i><para>one or more <emph style="italic">installations</emph> of the Tcl core and additional packages. Each installation may be configured differently (Tcl version, installed packages, platform, ...).</para></item.i><item.i><para>Installed packages are taken either from a <emph style="italic">distribution repository</emph> or directly from a built package. The latter has to be done in coordination with a <emph style="italic">P/A Builder</emph>.</para><para>Her responsibilities include</para></item.i><item.i><para>the creation of empty installations, </para></item.i><item.i><para>the destruction of installations,</para></item.i><item.i><para>the addition and removal of packages to/from an existing installation.</para></item.i></itemize></item.e></enumerate>
<para>The three P/A roles are central to the development process and bound together in a tight loop of information flowing between them. The other three roles handle the support structure without which the other roles would be unable to communicate and collaborate.</para>
<image src="78pa_cycle" />
<para>Examples:</para>
<itemize><item.i><para>Larry Virden is <emph style="italic">System-Administrator</emph>, <emph style="italic">P/A Builder</emph> and <emph style="italic">P/A User</emph> for his organization.</para></item.i><item.i><para>I (the author of this TIP) am all roles, on my system at home.</para></item.i><item.i><para>ActiveState is <emph style="italic">Repository Manager</emph> for the Perl community and plans to become one for the Tcl community.</para></item.i><item.i><para>SourceForge is a combination of <emph style="italic">Repository Manager</emph> and <emph style="italic">Catalog Manager</emph>.</para></item.i><item.i><para>Most people with a windows machine at home are <emph style="italic">System-Administration</emph> and <emph style="italic">P/A User</emph> for this machine.</para></item.i></itemize>
</section>
<section title="Visual Representation">
<para>The following drawings are a visual adjunct to the terms in the last sections to aid in the understanding of the terms and their relations.</para>
<para>Legend:</para>
<itemize><item.i><para>Blue rounded boxes - Areas of responsibility for roles. The responsible role is written in gold text inside of the box.</para></item.i><item.i><para>White rounded boxes with a black border - Data, like packages, distributions, etc.</para></item.i><item.i><para>White boxes with a red border - Actions on data.</para></item.i></itemize>
<image src="78tea_terms_relations_1" caption="Roles, Data and Actions" />
<image src="78tea_terms_relations_2" caption="Relationships Between Data Entities" />
</section>
<section title="Copyright">
<para>This document has been placed in the public domain.</para>
</section>
</body></TIP>
