For the time being the interface is pretty much thin, basic functions for parsing and allocating cpv and atom along with ebuild variables provided and comparison functions. Also provided corresponding python bindings and tests.
CPV *cpv_alloc(const char *cpv_string, int versioned);
void cpv_free(CPV *cpv);
void cpv_print(const CPV *cpv);
cmp_code cpv_cmp(const CPV *cpv1, const CPV *cpv2);
cmp_code cpv_cmp_str(const char *s1, const char *s2);
P, PN, PV, PR, PVR, PF, CATEGORY
ATOM *atom_alloc(const char *atom_string);
void atom_free(ATOM *atom);
void atom_print(const ATOM *atom);
cmp_code atom_cmp(const ATOM *atom1, const ATOM *atom2);
cmp_code atom_cmp_str(const char *s1, const char *s2);
int atom_intersect(const ATOM *atom1, const ATOM *atom2);
int atom_intersect_str(const char *s1, const char *s2);
P, PN, PV, PR, PVR, PF, CATEGORY, SLOT, SUBSLOT, REPO, USE_DEPS, atom operations(block, pfx, sfx)
cmp_code version_cmp(const char *v1, const char *v2);
int version_match(const char *v1, const char *v2, atom_op operation);
Restrictions interface.
Essentially we have restrictions for a package as well as for package data(license, required use etc) - package restrictions which receive other types of restrictions (values restrictions) which are strings matching (glob, exact, containments(list,strings) matching). The later represents various ebuild(package) attributes and can be grouped with boolean operators (and, or, also any match, exactly one, at most one) which are another type of restrictions(boolean restrictions). Eventually, when we want to find out whether packages(or data) are matched according to provided restrictions, the package match functions successively call underlying grouped values restrictions and yield the result.
There are a bunch of functionality that might be implemented in C but I still haven't a vision of the right design for it.
Perhaps for now I will switch to the implementation of other PythonC pkgcore modules and will figure out restrictions a bit later.
