-----BEGIN PGP SIGNED MESSAGE-----
yesterday jokey mentioned the whole bunch of find_*_packages and
find_all_*_packages functions that where existant in the current API.
The only difference has been, that the find_all_* functions take a regex
and the other ones get a package atom (like >=sys-apps/portage-2.13). He
proposed that they should be merged into only one set.
I also got reminded, that other package manglers provide certain
"package sets" - and I wanted to introduce them too.
The result: There is only one(!) function left out of them:
find_packages(key, pkg_set, masked, with_version).
What are the changes and the new requirements to implementations?
1.) The key can now either be an atom or a regex. The implementation has
to deal with it on its own.
Note: With "regex" I mean _real_ regexps. So the following should be
supported as a key: .*/.*dict-[abc]?en
This is NOT a valid regexp: *port* -> while this is: .*port* -> and
.*port.* would do the intended thing ;).
2.) We need to define a list of package sets that should be supported by
_all_ providers. Currently I have:
- "all" (or "") => all packages
- "installed" => all installed packages
- "uninstalled" => all uninstalled packages
- "world" => all packages in world
- "system" => all system packages
- "tree" => all packages where there is an ebuild for in the current
tree (might be different to "all" as you might have installed something
which has been removed from tree in the meantime)
3.) We need to define a behavior of what exactly masked and with_version
should do. Currently masked means "include masked packages" and
with_version makes the function return CPVs instead of CPs.
BUT: Especially the combination "with_version = False and masked =
False" is critical. Currently masked is ignored then. But should it
perhaps be changed so that only these CPs are returned which have at
least one unmasked version?
- - Change update_world into update_set("world").
- - What about the different system.get_*_option? Should they perhaps be
merged into one? - Do they make sense at all?
- - some more things I forgot :)
- - Please do not rely on the current portage provider implementation. The
API changes are not supported to 100% yet.
- - I'll try to update the wiki pages, but can't promise to finish it in
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
firstname.lastname@example.org mailing list