The functions provided by pkg/db do not actually manage packages; they do not change or consult the local database of installed modules in any package scope. The functions provided by pkg/db simply reflect a local copy of the information that a package catalog and individual package might provide (but with no guarantee of being in sync with an actual package catalog or package).
The database is implemented as an SQLite database with its own locking, so no additional locks are needed for database access, but beware of concurrent database changes that could break your program logic.
(current-pkg-catalog-file file) → void? file : path-string?
Added in version 220.127.116.11 of package base.
The result list is ordered by precedence of the package catalog.
Information about any other package for catalog is removed from the database. If a string is provided for pkgs, it is treated as a package name; if additional information is already recorded in the database for the package name, then the additional information is preserved.
If clear-other-checksums? is true, then for each element of pkgs that has a given checksum other than "", any information in the database specific to another checksum (such as a list of module paths) is removed from the database.
If clear-other-checksums? is true, then information (such as a list of module paths) is removed from the database when it is specific to a checksum other than checksum.
(get-pkg-ring name catalog)
→ (or/c #f exact-nonnegative-integer?) name : string? catalog : string?
name : string? catalog : string? ring : (or/c #f exact-nonnegative-integer?)
The PLT-supported package catalog reports a curated ring number to reflect advice on package preference and conflicts, where the set of ring-0 and ring-1 packages are expected to have no conflicts (that is, no multiply defined modules, document names, etc.). The raco pkg tool does not pay attention to a package’s ring number, but other uses of a catalog may consult ring numbers.
Added in version 18.104.22.168 of package base.
The list of dependencies must have the shape described for a deps "info.rkt" field as described in Package Metadata. The result from get-pkg-dependencies is normalized: each dependency is represented by a list, a version in a dependency is always preceded by '#:version, and if both version and platform specification are included, '#:version appears before '#:platform.
name : string? catalog : string? checksum : string?
(set-pkg-modules! name catalog checksum module-paths) → void? name : string? catalog : string? checksum : string? module-paths : (listof module-path?)
Each resulting pkg has its name, catalog, and checksum field set, but other fields may be "".