|Title:||TEA 2.0 Definitions|
|Version:||$Revision: 1.4 $|
Andreas Kupries <andreas_kupries at users dot sourceforge dot net>|
Larry W. Virden <lvirden at yahoo dot com>
|Created:||Saturday, 15 December 2001|
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.
This document is an adjunct to the [TIP <<vision>>]. (DKF - Is this meant to be a reference to TIP #34? Edit to such if so...)
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.
This section specifies a number of important technical terms in alphabetical order. Terms used inside of a specification are highlighted.
An entity implementing some functionality required by a P/A User (see section Roles) to perform his work. Consists of one more files. May make use of packages to implement its functionality.
Encapsulation of a distribution in a single file. Well-known formats for archives are tar, gzipped tar, bzipped tar, and zip.
The process of wrapping up a built package into a binary distribution. See building too.
The process of configuring and transforming a source distribution into a set of files which can be either immediately installed on the site which built them or wrapped into a binary distribution for shipment to other sites. This also includes the execution of a test-suite coming with the package.
A distribution encapsulating more than one package.
A catalog is a site providing an index of the packages.
The process of customizing a source distribution for a particular architecture and/or site. A part of Building.
Two or more packages are said to be in conflict if the usage of one of them excludes the usage of the others.
In a strong conflict installing one of the packages disallows even the installation of the others.
A shorthand for Tcl core.
See Tcl core distribution.
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.
There are several types of dependencies:
Y is required to allow X to be build.
Y is required to allow the usage of an installed X.
Y can be used by X (usually for improved performance) but is not required for building or use.
An encapsulation of one or more packages for transport between places, machines, organizations, and people. Several types of distributions are possible, explained below.
A binary distribution is in a state and format allowing the installation of the contained packages on a particular platform.
It contains at least all the files
implementing the functionality of the distributed packages and
required to allow the package management of the Tcl core to handle the packages.
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 fat binary distribution.
We distinguish between three sub-types:
This is the minimal binary distribution we spoke of before.
Like installable', 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.
Like auto-installable, 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.
Some of the existing archive formats restrict their contained distributions to this type. Examples of such archive formats are
RPM (RedHat Package Manager)
DEB (DEBian Linux package format)
See [TIP 55] for the specification of a proposed layout for binary distributions.
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.
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 Preparation.
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.
The execution of autoconf to generate a configure script from its configure.in file can be a single step in a complex preparation.
A source distribution is in a format and state where tools can be used to build its contents.
The format needs further specification but for now we can assume that it is governed by the current TEA specification.
Alternate name for this type of distribution are compileable and buildable.
Alternate name for a package, generally used for packages requiring compilation to become functional.
This term is deprecated.
A special type of distribution repository, binary (see repository) containing all packages 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.
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 P/A Developers.
The process of unpacking a binary distribution and adding the contained packages to an installation. The latter may include moving files to their proper places.
Also the process of adding a built package to an installation.
A file detailing the files making up a particular package.
A collection of files providing additional functionality to a user of a Tcl interpreter when loaded into said interpreter.
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.
The process of converting a raw distribution into a source distribution suitable as input to building. This includes actions like:
Retrieval of sources from a source repository
Creating a configure file from its configure.in.
Creating the distributed documentation from internal sources.
Removal of internal files containing notes, scratch info and the like.
Inserting version information into files.
The tool makedist (which I wrote) is in my mind when thinking about this step.
The process of retrieving a raw distribution from a source repository.
General term with two possible meanings.
A collection of archives. The exact term for this type of repository is "distribution repository".
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
distribution repository, binary, or
distribution repository, source.
A collection of directories, developer files and control files containing version control information. The exact term for this type of repository is source repository.
A repository can either be internal to an organization or public.
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 info commands for a tclsh which was started with an empty .tclshrc file and after sourcing all .tcl files in the directory returned by info library.
Tcl core distribution
The most fundamental distribution there is. Contains the Tcl core and a number of packages.
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.
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.
Examples are given at the end of this section.
A catalog manager handles one or more catalogs. He is responsible for
the final name arbitration for packages with conflicting names
and the categorization of the packages indexed by the catalog.
A package and/or application builder is a person and/or organization
who retrieves raw distributions from source repositories and (in a sequence of several steps) generates binary distributions from them.
or who retrieves source distributions from distribution repositories and (in a sequence of several steps) generates binary distributions from them.
uploads the generated binary distributions into one or more distribution repositories.
uploads the generated source distributions into one or more distribution repositories.
The intermediate steps performed by a builder are Preparation, Building, and Binary generation.
If System administrator and P/A Builder coordinate with each other it is also possible to install a package directly from the built package.
NOTE: Think about splitting P/A Builder into two roles; one for the preparation of source distributions and a second role for the generation of binary distributions.
TODO Find some nice names for the split roles.
A developer is a P/A User 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 source repositories.
During development, at least one installation has to be accessible, containing the initial packages, the new packages and the applications built upon the packages.
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.
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.
This role handles the management of all types of repositories. This role is not part of the development process per se and has no direct actions for with regards to distributions, packages, sources, etc.
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.
The role is related to System administrator, but not the same. It was split out of that role because a System-Administrator is usually internal to an organization whereas a repository and its management can be provided by an entity external to the organization.
A system administrator manages
one or more installations of the Tcl core and additional packages. Each installation may be configured differently (Tcl version, installed packages, platform, ...).
Installed packages are taken either from a distribution repository or directly from a built package. The latter has to be done in coordination with a P/A Builder.
Her responsibilities include
the creation of empty installations,
the destruction of installations,
the addition and removal of packages to/from an existing installation.
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.
Larry Virden is System-Administrator, P/A Builder and P/A User for his organization.
I (the author of this TIP) am all roles, on my system at home.
ActiveState is Repository Manager for the Perl community and plans to become one for the Tcl community.
SourceForge is a combination of Repository Manager and Catalog Manager.
Most people with a windows machine at home are System-Administration and P/A User for this machine.
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.
Blue rounded boxes - Areas of responsibility for roles. The responsible role is written in gold text inside of the box.
White rounded boxes with a black border - Data, like packages, distributions, etc.
White boxes with a red border - Actions on data.
This document has been placed in the public domain.
[Index] [History] [Edit] [HTML Format] [Source Format] [LaTeX Format] [Text Format] [XML Format] [*roff Format (experimental)] [RTF Format (experimental)]TIP AutoGenerator - written by Donal K. Fellows