openbsd-ports/databases/sqlports/pkg/DESCR-compact
2013-03-11 11:53:51 +00:00

115 lines
3.6 KiB
Plaintext

SQLite database of every port in the system. This can be queried through
e.g., sqlitebrowser, or any kind of programming interface.
This schema is mostly optimized for tools, and cumbersome to query by
hand.
Database Schema:
- Paths (ID, FULLPKGPATH, PKGPATH, CANONICAL)
PKGPATH points to a PATHS entry corresponding to the stripped down version of
FULLPKGPATH, without flavors or subpackage markers, or is null if FULLPKGPATH
is already stripped. Every other FULLPKGPATH, PKGPATH, DEPENDSPATH entry
in the database points to this table.
The FULLPKGPATH is complete, including flavors and pseudo flavors markers.
For every port with MULTI_PACKAGES settings, one entry is written
for each SUBPACKAGE.
CANONICAL points to the actual ID to use as an entry in other tables, for
FULLPKGPATH which don't have their own entry.
- Ports(FULLPKGPATH, ...)
holds all the information retrieved through various variables that is not
stored in specialized tables, e.g.,:
AUTOCONF_VERSION
AUTOMAKE_VERSION
BROKEN
COMMENT
DESCR
DISTFILES
DISTNAME
DIST_SUBDIR
EPOCH
FLAVORS
FULLPKGNAME
HOMEPAGE
IS_INTERACTIVE
MAINTAINER
MULTI_PACKAGES
NO_*
PERMIT_*
PKGNAME
PKGSPEC
PKG_ARCH
PSEUDO_FLAVOR
PSEUDO_FLAVORS
TEST_IS_INTERACTIVE
REVISION
SEPARATE_BUILD
SHARED_ONLY
STATIC_PLIST
SUBPACKAGE
SUPDISTFILES
USE_*
This information is mostly unchanged, except for replacing Yes/No variables
with 1/0. Variables not present in a given port are left undefined.
Note that USE_LIBTOOL is 3-valued: 2 is gnu, 1 is yes, undef is no.
MULTI_PACKAGES ports hold several entries with corresponding FULLPKGPATH
- Flavors(FULLPKGPATH, VALUE)
- PseudoFlavors(FULLPKGPATH, VALUE)
- Categories(FULLPKGPATH, VALUE)
- Multi(FULLPKGPATH, VALUE, SUBPKGPATH) ('-' values are not stored)
- Modules(FULLPKGPATH, VALUE)
- Configure(FULLPKGPATH, VALUE) (corresponds to CONFIGURE_STYLE)
- ConfigureArgs(FULLPKGPATH, VALUE)
- MasterSites(FULLPKGPATH, N, VALUE)
- NotForArch(FULLPKGPATH, VALUE)
- OnlyForArch(FULLPKGPATH, VALUE)
All of these variable values are actually lists. These lists are taken apart
and result in many entries in these secondary tables (or none if the list
is completely empty)
Each keyword table follows the same scheme
TABLENAME(KEYREF, VALUE)
- Depends(FULLPKGPATH, FULLDEPENDS, PKGSPEC, REST, DEPENDSPATH, TYPE)
All depends are stored in a single table, including the type:
0 -> library
1 -> run
2 -> build
3 -> test
with FULLDEPENDS the full text of the dependency, DEPENDSPATH the PKGPATH
we depend upon, PKGSPEC the spec we depend upon (if explicit), and REST
the rest.
- Wantlib(FULLPKGPATH, VALUE, EXTRA)
All the libraries the FULLPKGPATH depends upon, with optional version
number specification stored in EXTRA
coming from either the WANTLIB variable or various LIB_DEPENDS.
- Multi(FULLPKGPATH, VALUE, SUBPKGPATH)
also contains the normalized pkgpath for the corresponding subpackage.
- Broken(FULLPKGPATH, ARCH, TEXT)
This is stored both in the main table (for now) and in a separate table, with
keywords since it may be arch-dependent
- Shared_Libs(FULLPKGPATH, LIBNAME, VERSION)
- TARGETS(FULLPKGPATH, VALUE)
Some information, both in the main table and in secondary tables
is stored as keyword references to other tables:
AUTOCONF_VERSION, AUTOMAKE_VERSION -> AUTOVERSION
MAINTAINER -> EMAIL
CATEGORIES -> CATEGORYKEYS
CONFIGURE -> CONFIGURE_KEYS
MODULES -> MODULEKEYS
WANTLIB.VALUE, SHARED_LIBS.LIBNAME -> LIBRARY
PERMIT_*, SEPARATE_BUILD -> KEYWORDS2
FLAVORS, PSEUDO_FLAVORS -> KEYWORDS
NOT_FOR_ARCHS, ONLY_FOR_ARCHS, PKG_ARCH -> ARCH
TARGETS -> TARGETKEYS