pkg

CATALOG AND INVENTORY OPERATIONS

[Suspended] Premise 1:  From the client's perspective, the catalog is just

another package.  (It's only special in that its contents drive

automatic package operations.)

   Because we pull catalogs from multiple repositories, managing N

   packages for N repositories seems overcomplicated.

Premise 2:  From the server perspective, the catalog is a file whose

contents are updated as a result of the set of packaging operations that

have occurred within the server's repository.  (No operation ever

affects the catalog directly.)

1.  Server catalog

The primary content of the catalog is the relationships between

packages.  We've already said that there are packages that depend on

other packages and packages that incorporate other packages.  These

latter packages, the base- and stack-style packages, are really packages

that, in addition to listing a set of packages, also freeze those

packages, such that it takes a relaxation of the base/stack package for

the client to modify the incorporated packages.

The detailed manifest for each package contains the dependencies,

contents, and actions.  But, as it seems that the set of incorporation

relationships are of particular interest for reporting and determining

package retrieval ordering, we place incorporation dependencies in the

catalog as well.

It's reasonably clear that the package repository needs to have

observations of package popularity, so that the most aged packages can

be purged, once unneeded.

2.  Client catalog and client inventory

The client catalog is a compilation of package sourcing information from

a collection of repositories, in the form of one server catalog per

repository.  Its purpose is to advertise what package versions are

"available", which means that it is the union of the repositories it

sources.

In contrast, the client inventory is the set of packages currently in an

installation state on the system, stored in some representation.  One

form of this representation will be in the form of a server catalog.

The inventory is stored under 

/var/pkg/db

If some instance of [email protected] is installed, we would have a directory

/var/pkg/db/pkg/[publisher?]/which/2.16

				publisher

				manifest

				state

XXX Can we have two packages with the same name, but from different

publishers?

An open question is whether we store one or more reverse indices in the

inventory.  We could have indices into basenames, pathnames, and

contents, which would look something like:

/var/pkg/db/index/

		{basename,path}/

			[escaped basename or full path]/

				named links to content files

		content/

			[SHA1 hash of contents] -> package directory

Unfortunately, since FILE_MAX < PATH_MAX, the escaped representation for

full paths is insufficient, and we might need to provide a hash-based

directory name, and a metadata file with the full path.

2.1.  Multiple catalogs

If a package is available from two or more repositories, we have a

choice:  we can prefer a repository (as we would for a request for a

first installation of a package), or we can store both catalogue

entries.

In a directory-based approach, we might have

/var/pkg/catalog/repository_publisher/category/package/versions

with example

/var/pkg/catalog/pkg.opensolaris.org/application/which/2.16

/var/pkg/catalog/blueslugs.com/application/which/2.16

In a file-based approach, we would have

/var/pkg/catalog/[escaped_catalog_URL]

...

XXX Investigate efficiency of encoding versions as entries in

a file versus encoding as separate files

XXX Are FMRI-level categories actually a help, or is a detailed,

hierarchical namespace going to get in the way?