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
FIX_EXTRACT_PERMISSIONS
FLAVORS
FULLPKGNAME
GH_*
HOMEPAGE
IS_INTERACTIVE
MAINTAINER
MULTI_PACKAGES
NO_*
PERMIT_*
PKGNAME
PKGSPEC
PKG_ARCH
PREFIX
PSEUDO_FLAVOR
PSEUDO_FLAVORS
TEST_IS_INTERACTIVE
REVISION
SEPARATE_BUILD
STATIC_PLIST
SUBPACKAGE
SUPDISTFILES
USE_*
README
COMPILER
COMPILER_LANGS
COMPILER_LINKS
This information is mostly unchanged, except for replacing Yes/No variables
with 1/0. Variables not present in a given port are left undefined.
README corresponds to README files (full text value) and only exists when
such files are present.
Note that USE_LIBTOOL is 3-valued: 2 is gnu, 1 is yes, undef is no.
Note that USE_WXNEEDED is 3-valued: 2 is special, 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)
- _Makefiles(FULLPKGPATH, 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)
The Makefiles table contains only Makefiles from MAKEFILE_LIST that are not
"default values" (always included makefiles).
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
MAKEFILES -> FILENAMES
MODULES -> MODULEKEYS
PREFIX -> PREFIX
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
No homepage
None