EDOS Glossary
Last modified by Arkub on 2007/09/11 15:39
EDOS Glossary
| Term | Definition |
|---|---|
| abundance | every package has what it needs, i.e., its dependencies are satisfied |
| co-installable | a set of packages S is co-installable with respect to a repository R if the abundance and peace conditions hold for a subrepository R' of R containing S. In simpler words, S is co-installable w.r.t. R if we can install all the packages of S together, using only packages from R. |
| conflict | An incompatibility between two packages. Conflicts are given by a symmetric relation. |
| consistent | see co-installable |
| dependency | A dependency is an abstract notion referring to the fact that a package may require other packages to be installed in order to run. See dependency function. More precisely, a dependency is a conjunction of disjunctions of packages. For the dependency to be satisfied, there must be at least one installed package in each disjunction. At this stage of analysis, we do not distinguish Debian Depends: and Pre-depends: fields. |
| dependency closure | The dependency closure of a package is the set of dependencies of that package, dependencies of the dependencies of that package, and so on. |
| dependency function | A function that maps packages to their dependencies, represented as sets of disjunctions of packages, taken as a conjunction. |
| developer | Someone who participates in a project. Roles include developer, manager, documentation writer. |
| distributed hash table | "Distributed hash tables (DHTs) are a class of decentralized distributed systems that partition ownership of a set of keys among participating nodes, and can efficiently route messages to the unique owner of any given key. Each node is analagous to a bucket in a hash table. DHTs are typically designed to scale to large numbers of nodes and to handle continual node arrivals and failures. This infrastructure can be used to build more complex services, such as distributed file systems, peer-to-peer file sharing systems, cooperative web caching, multicast, anycast, and domain name services" Source |
| distribution | A distribution of a given operating system is a project aiming to (a) allow the installation of said operating system and (b) provide a packaging system and porting existing products to it. |
| release | A release of a distribution is a set of packages where there is exactly one version for each unit of each ported product. There can be conflicts among packages in the release (e.g. two different and incompatible web-servers). |
| Egraph data format | An extension of the GraphML file format. It's main elements are: nodes: They are used to model packages which are present in a given package base, edges: They are used to model simple relationships between two packages, hyperedgess: They are used to model "alternative" relationships between a set of packages. |
| generated subrepository | The subrepository generated by a package is the restriction of the repository to the dependency cone of the package. |
| GraphML | GraphML is a comprehensive and easy-to-use file format for graphs. It consists of a language core to describe the structural properties of a graph and a flexible extension mechanism to add application-specific data. Its main features include support of directed, undirected, and mixed graphs, hypergraphs, hierarchical graphs, graphical representations, references to external data, application-specific attribute data, and light-weight parsers. Unlike many other file formats for graphs, GraphML does not use a custom syntax. Instead, it is based on XML and hence ideally suited as a common denominator for all kinds of services generating, archiving, or processing graphs. ~~Source: http://graphml.graphdrawing.org |
| healthy installation | An installation which is co-installable, i.e., where the peace and abundance conditions hold. |
| history | An history is a sequence (R_t)_{t >= 0} of repositories, representing their evolution in time. |
| installable | A package is installable if there is a consistent installation which includes it. |
| installation | An installation is a subset of package taken from a distribution which is currently installed on a running system. An installation cannot be inconsistent. But it can become so if we try to modify an installation by trying using the usual install/remove/upgrade operations. See also healthy installation. |
| maintainer | Someone who ports a product to a distribution. |
| monotone | A history (R_t) is monotone if, whenever we have a set X of co-installable packages in R_t, there is a future X' of Xin R_{t+1} such that X' is co-installable in R_{t+1}. |
| multicast | "Multicast is the delivery of information to a group of destinations simultaneously using the most efficient strategy to deliver the messages over each link of the network only once and only create copies when the links to the destinations split. By comparison with multicast, conventional point-to-single-point delivery is called unicast. When unicast is used to deliver to several recipients, a copy of the data is sent from the sender to each recipient, resulting in inefficient and badly scalable duplication at the sending side. Many popular protocols like XMPP accept this shortcoming however, and limit the amount of possible recipients instead." Source |
| package | A package is a computer file, for instance in .deb or RPM format. It is versioned and possibly architecture-specific. If the architecture and the distribution are fixed, we identify packages and package identifiers. |
| source package | A source package contains only source files and documentation. No dependencies a priori exist for the source packages but there may have to make the package usable (for example to compile it). |
| binary package | A binary package contains compiled code targeted to a specific architecture. The name of the architecture can usually be found on the package file name and within its meta-data. A binary package may not contain all the code needed to run it, which can be found in other dependent binary packages. |
| package identifier | A pair (u,v) where u is a unit name and v is a version string. These are the basic nodes in all the dependency resolution problems. If the distribution and architecture are specified, a package is uniquely identified by such a pair. For example, (emacs21, 21.4a-3) uniquely identifies the package emacs21_21.4a-3.deb. |
| peace | there are no conflicts. |
| pool (of packages) | A pool contains a set of packages where each package may have more than one version with different requirements. Different packages in the pool may be in conflict among them (e.g. two different versions of the same package type). The pool is used as the "package universe" from which it is possible to extract a release. Since many releases depend on the same pool (e.g. Debian), maintaining some properties of the pool is crucial in order not to break the releases which are built on top it. |
| port | The incorporation of a product into a (Linux or other) distribution. This will require writing control and metadata files and writing or applying adequate patches. The port of a product gives one or more units. |
| product | A piece of software made by the OSS community. For example, konqueror is a product of the KDE project ; Linux 2.6 is a product of the Linux project, Emacs is a product of its own project, and so on. |
| project | Cooperation between different developers, with feedback from the user community, for developing programs, documentation, and so on. Examples: Sourceforge projects. Linux is a project, KDE and Gnome are projects. |
| repository | A tuple R = (P,D,C) where P is a set of packages identifiers, D is the dependency function, and C is the conflict relation. |
| SAT temperature | Given a 3SAT formula in conjunctive normal form made of m clauses and n variables, its temperature is defined as the ratio T = m / n. The probability for a random 3SAT formula to be satisfiable tends to 1 as T tends to 0, towards 0 as T tends to infinity, and undergoes a sharp transition from 1 to 0 at T ~= 4.2. |
| SLOC | Source line of code (SLOC) Since we rely on David A. Wheeler's SLOCCount tool for counting physical SLOC, we also rely on his definition for "physical source lines of code". Therefore, we could say that we identify a SLOC when SLOCCount identifies a SLOC. However, SLOCCount has been carefully programmed to honor the usual definition for physical SLOC: "A physical source line of code is a line ending in a newline or end-of-file marker, and which contains at least one non-whitespace non-comment character." There is other similar measure, the "logical" SLOC, which sometimes is preferred. For instance, a line written in C with two semicolons would be counted as two logical SLOC, while it would be counted as one physical SLOC. However, for the purposes of this paper, the differences between both definitions of SLOC are not that important, specially when compared to other sources of error and interpretation. |
| software component | Szyperski(1998) defines a component as an independently deployable executable unit of composition. In the context of a Linux distribution, a component is a set of files which are installed (removed) together and which constitute a semantic unit. As Bay and Pauls(2004) explain, a component comes with 2 resulting features: composition and dependency. In a Linux distribution composition is seldom used, within the virtual packages. But dependency is very common and it turned into an issue. |
| software measurement process | Software measurement process is the portion of the software process that provides for the identification, definition, collection, and analysis of metrics that are used to understand, evaluate, predict, or control software processes or products. |
| source and binary packages | Packaging systems consider two kind of packages: source and binary. One or more binary packages can be built automatically from each source package. For instance, from a certain source package maybe three different binaries packages are built: one with a library, another with and executable program and a third one with documentation. For this paper, only source packages are relevant, and therefore we will no longer refer to binary packages. (from "Measuring Woody") |
| subrepository | A repository that can be obtained by appropriately restricting a repository to a subset of its packages. |
| upgradeable | A repository R_t in a given history is upgradeable if, for every package p of R_t, there is a future p' of p in R_{t+1}, and p' is installable in R_{t+1} |
| trimmed repository | A repository that has no non-installable packages. Note that the set of packages of the repository itself does not need to be co-installable (this won't be possible if there are conflicts). |
| unit | The port of a product gives one or more units. For instance, the ara product gives xara-gtk, ara, ara-byte and xara-gtk-byte units, and emacs21 gives emacs21, emacs21-bin-common, emacs21-common, emacs21-el, emacs21-nox units. |
| upstream packaging | The upstream developer/maintainer may or may not provide a package for the end user to use. This process is entirely optional, as many developers feel that the packaging process should be the responsibility of the distribution vendor, while their own responsibility is to provide a source that compiles and works. However, since it can take some time for new (or updated) software to be packaged by the distribution vendors (it may take some months in some cases, and sometimes the distribution vendor may decide not to package a certain project at all), the maintainer may choose to package the project himself - in order to bring the project quickly to many users. Another possibility is that a third party may package the project. For example, an end user might download the source code from the maintainer's site, compile, install and then package the project so it will be easier for other users. This may cause different packages of the same software circulating around, some "official", some "non-official", some working properly and some buggy. It may be difficuly to know exactly which package is "right", as long as there's no official one by the maintainer or the distribution vendor. |
| upstream publishing | When the maintainer of a software project has decided to make a new release available to the public, she needs to announce that the new release is available. The de-facto standard for this is freshmeat.net. This is a moderated site whose administrators receive a constant input of new projects and releases and publish the data on the site. It is possible to subscribe to certain projects and receive notifications via email whenever new version is available. It is also possible to get notifications about new projects, meeting specified criteria (for example, one may choose to get notifications on new multimedia projects). When a project is published in Freshmeat, links are specified for its versions' files, including the source code files, the maintainers' home page, and also links to package files - if these were provided by the maintainers. |
| user | Someone who uses a product. |
| version | A version number is a string, with special lexical conventions, and a particular ordering, that allows to uniquely identify a set of sources for a given product. For instance, 2.6.14.2 uniquely identifies the sources of the 2.6.14.2 kernel of the Linux 2.6 product of the Linux project. |
| virtual package | A virtual package is a package which contains no concrete files but instead a list of required packages which ask be installed. Virtual packages allow to install a suite of packages, such as KDE, by refering to only one package (in that case kde). |