Lines Matching full:package
15 package tools, but also includes L<pkg-config(1)> support modules.
16 This document only covers package tools material.
18 The design of the package tools revolves around a few central ideas:
21 that they can be used by the package tools proper, but also with a
31 Traditional package tools often rely on the following model: take
35 Instead, OpenBSD package tools take a computational approach: record
50 module that allows package tools to manipulate tarballs directly without
53 All the package tools use the same internal perl modules, which gives them
57 elements first, since they are the core that unlocks most of the package
67 Each package consists of a list of objects (mostly files, but there are some
69 the package gets installed).
91 For instance, package installation happens through the following snippet:
98 =item package names and specs
100 Package names and specifications for package names have a specific format,
101 which is described in L<packages-specs(7)>. Package specs are objects
108 allows the package system to resolve dependencies in
109 L<OpenBSD::Dependencies(3p)> and to figure out package
118 on the local machines, or distant. Once a package is located, the repository
123 =item package sets
127 stability of the installed system. The package tools
142 L<pkg_delete(1)> also uses package sets, but a simpler variation, known as
150 PackageSets contain some initial information, such as a package name to
151 install, or a package location to update.
155 how to update each element of an updateset, if it is an older package, or
156 to resolve a hint to a package name to a full package location.
159 object keeps track of all the package name statuses: what's queued for
169 specifications with more constraints when the package is built by
171 objects when the package is installed, and recorded as lists of
172 inter-dependencies in the package system.
174 At the package level, there are currently two types of dependencies:
175 package specifications, that establish direct dependencies between
178 Normal dependencies are shallow: it is up to the package tools to
181 work, as we do not want to depend on a specific package if something
184 At the same time, shared libraries have harsher constraints: a package
216 Most package operations will lead to the installation and removal of some
217 files. Everything is checked beforehand: the package system must verify
219 won't overflow during the package installation.
220 The package tools also have a "pretend" mode where the user can check what
248 There are three basic operations: package addition (installation),
249 package removal (deinstallation), and package replacement (update).
254 =head2 PACKAGE ADDITION
256 For package addition, L<pkg_add(1)> first checks that everything is correct,
259 =head2 PACKAGE DELETION
261 For package deletion, L<pkg_delete(1)> removes elements from the packing-list,
266 =head2 PACKAGE REPLACEMENT
268 Package replacement is more complicated. It relies on package names
272 files in the new package don't already exist in the file system.
274 versions of the same package, e.g., screen-1.0 and screen-1.1 correspond
286 information to figure out which package(s) it should replace. It will then
287 operate in a specific mode, where it replaces old package(s) with a new one.
293 determine which package to replace through conflict information
297 extract the new package 'alongside' the existing package(s) using
302 remove the old package
306 finish installing the new package by renaming the temporary files.
311 conflict markers. pkg_add -r will happily replace any package with a
312 conflicting package. Due to missing information (one can't predict the
316 =head2 PACKAGE UPDATES
318 Package replacement is the basic operation behind package updates.
319 In your average update, each individual package will be replaced
322 old shared libraries are kept around in a stub .lib-* package, so that
328 to figure out the new package name from the old one.
331 a package may replace an older one if it conflicts with it. But an older
332 package can only be updated if the new package matches (both conflicts and
336 the quirks package, which contains a global list of exceptions, such as
337 extra stems to search for (allowing for package renames), or packages to
340 This search relies on stem names first (e.g., to update package
342 the search results by looking more closely inside the package candidates.
344 they were compiled). Thus, a package
345 that comes from category/someport/snapshot will never replace a package
349 the package version and the package signatures: a package will not be
350 downgraded to an older version. A package signature is composed of
351 the name of a package, together with relevant dependency information:
364 common operations related to a package addition.
368 common operations related to package addition/creation/deletion.
394 common operations related to package deletion.
412 proxy class to go from a package location to an opened package with plist,
450 handles package meta-information (all the +CONTENTS, +DESCR, etc files)
454 proxy for a package, either as a tarball, or an installed package.
464 common operations on package names.
468 base class for all package sources. Actual packages instantiate as
473 list of package repository, provided as a front to search objects,
500 ad-hoc search for package specifications. External API is stable, but it
511 common operations related to package replacement.
519 search object for package repositories: specs, stems, and pkgpaths.
531 handles package signatures and the corresponding version comparison (do not
550 tracks all package names through update operations, in order to avoid
555 incremental computation of package replacements required by an update or
560 common operations to all package tools that manipulate update sets.