From 48d39031df987b97af31bab1438a2f6322fddbcb Mon Sep 17 00:00:00 2001 From: Marc Espie Date: Wed, 31 Aug 2011 09:18:48 +0000 Subject: synch with current state of affairs a bit --- usr.sbin/pkg_add/pod/OpenBSD::Intro.pod | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) (limited to 'usr.sbin/pkg_add/pod') diff --git a/usr.sbin/pkg_add/pod/OpenBSD::Intro.pod b/usr.sbin/pkg_add/pod/OpenBSD::Intro.pod index 6cb4a7bed40..e9c6cf0ebe9 100644 --- a/usr.sbin/pkg_add/pod/OpenBSD::Intro.pod +++ b/usr.sbin/pkg_add/pod/OpenBSD::Intro.pod @@ -1,4 +1,4 @@ -$OpenBSD: OpenBSD::Intro.pod,v 1.15 2010/06/30 10:51:04 espie Exp $ +$OpenBSD: OpenBSD::Intro.pod,v 1.16 2011/08/31 09:18:47 espie Exp $ =head1 NAME @@ -99,12 +99,15 @@ and invokes C and shows a progress bar if needed. =item package names and specs Package names and specifications for package names have a specific format, -which is described in L. Package names are handled -within L. There is also a framework to organize -searches based on L objects. Specifications are -structured in a specific way, which yields a shorthand for conflict handling -through L, allows the package system to resolve -dependencies in L and to figure out package +which is described in L. Package specs are objects +created in L, which are then compared to objects +created in L. Both classes contain further functions +for high level manipulation of names and specs. +There is also a framework to organize searches based on L +objects. Specifications are structured in a specific way, which yields +a shorthand for conflict handling through L, +allows the package system to resolve dependencies in +L and to figure out package updates in L. =item sources of packages @@ -118,7 +121,7 @@ yields a proxy object called L that can be used to gain further info. (There are still shortcuts for installed packages for performance and simplicity reasons.) -=item update sets +=item package sets Each operation (installation, removal, or replacement of packages) is cut up into small atomic operations, in order to guarantee maximal @@ -137,10 +140,15 @@ depends on A-0.0), or where files move between packages, which in theory will require update-sets with two new packages that replace two old packages. We still cheat in a few cases, but in most cases, L will recognize those situations, and merge updatesets as required. +L also uses package sets, but a simpler variation, known as +delete sets. Some update operations may produce inter-dependent packages, +and those will have to be deleted together, instead of one after another. +L contains the code for both UpdateSets and DeleteSets +for historical reasons. =item updater and tracker -Updatesets contain some initial information, such as a package name to +PackageSets contain some initial information, such as a package name to install, or a package location to update. This information will be completed incrementally by a @@ -152,6 +160,9 @@ In order to avoid loops, a C tracker object keeps track of all the package name statuses: what's queued for update, what is uptodate, or what can't be updated. +L uses a simpler tracker, which is currently located inside +the L code. + =item dependency information Dependency information exists at three levels: first, there are source -- cgit v1.2.3