-----BEGIN PGP SIGNED MESSAGE-----
My replies ;)
One important remark: I always see the things from the API-user view. I
have to use this API in a package manager GUI and thus want to have the
API to specify certain functionality.
Ciaran McCreesh schrieb:
> * use of cpv throughout. cpv isn't enough to uniquely identify an ID,
> especially if there're overlays. cpvr is closer, but still doesn't
> work if you need to deal with virtuals directly (rather than the thing
> provided by the virtual)
CPVR sounds reasonable ... and what about using virtual/* for virtuals?
Btw: There was the idea of providing a "get_virtuals" function....
> * use of regexes throughout. Every language defines its own, different
> regex dialect. There's no portability between languages.
True - I thought of using some kind of globbing - thus only allowing "*"
and "?" (and perhaps "^" and "$")
> * No mention of EAPI anywhere.
Why would this be needed? This is only true if "catapult API" == "EAPI".
> * No mention of error handling anywhere.
True. Currently exceptions are only passed to the caller - but this
should definitly be specified somewhere.
> * Generally lots of hard-coded ebuildy things that don't map well onto
> future EAPIs or handling of non-ebuilds (e.g. native CRAN support).
For me - gentoo package management is all about ebuilds. So I can't see,
what should changed there.
The only thing that should be provided is a feature similar to EAPI (the
"catapult API"), so that additional stuff can be specified later on. I
don't see a point in thinking about things, that may come somewhere in
> * It's tied onto a single user configuration setup, and has no sane way
> of handling multiple configurations or unconfigured operation.
I don't understand this ...
> * sets don't map on to package manager sets.
This can easily be changed. But nevertheless, some catapult-wide sets
should be defined, that map onto the specific ones in the package
managers (e.g. catapult.SET_ALL should be replaced by the specific set
in the different managers)
> * Administration:
> - version. But no name?
I saw this myself some days ago... Really a flaw - but one simple to fix ;)
> - find_best. What does this do if you give it foo/bar-1 foo/baz-1?
> What's the point of having this function at all?
See very first remark.
> - find_best_match. What's a search key? If it's a spec, it needs an
> associated EAPI.
> What if only_installed is false? Does this mean we
> want both not installed and installed stuff?
Yes. - But perhaps, instead of the "only_installed" flag used here and
there, a set-name should be provided. (Which then can be "installed",
"uninstalled" or whatever).
> - find_packages. As find_best_match for search key. What disambiguation
> is performed upon the atom? What happens if you pass it something like
> 'git', which is ambiguous?
Return everything that fits. It should be on the users side to translate
it into something useful.
> - get_config_path. Unportable. What if the user is using some other
> config format?
But the configs (read: package.mask, package.use etc.) have to be at a
specified unique location, don't they?
> - get_deep_option. Deep's a mess; making package managers emulate it via
> a command line switch is silly.
If you don't have an equivalent: Return "".
> - get_environment. In no way portable.
True. Should be dropped. I used it to get unwanted things out of the
environment. (E.g. modify EMERGE_DEFAULT_OPTS). But this is really a
user thing and should not be here.
> - get_global_key. Again, unportable -- Paludis has no notion of global
get_global_settings and get_package_settings should be merged anyway.
> - get_merge_command. There's no nice way of using whatever this returns.
> And it's pointless -- why not just ask the package manager to do the
Because catapult should be passive: I.E. only provide information and
does not do anything that could be harmful.
> And what about package managers that require an explicit
Return: ["pkgmgr", "--install"]. Everything that has "get_xxx_command"
should return the complete commandline.
> - get_newuse_option. Again, unportable and messy.
> - get_oneshot_option. Again, unportable and messy.
Why unportable? - See the remarks to "--deep".
> - get_pretend_option. Again, unportable and messy. And probably useless
> -- what would you do with this?
> - get_updated_packages. Highly unclear what this really does.
Returns a list of packages, that can be updated. Similar to what
"eix-sync" shows at the end of the run.
> - get_world_file_path. Unportable.
> - list_categories. String or regex?
Has to be defined.
> - sort_package_list. You don't want stuff sorted the way it's sorted by
> Paludis. You might want a well defined sort.
> - split_cpv. Why the weird revision thing?
What's so weired about it?
> - update_world. Huh? In some ways pointlessly specific, in some ways way
> too vague. And what's this use flag stuff? We finally just about got
> people away from setting use flags in places other than config files,
> and for good reason.
Rember: Passive. It should return the packages, that WOULD be updated,
if a world-update (or alike) would be run. The parameters are there, to
run different scenarios. (Portato for example uses this, to generate the
list - taking into account the user saved flags, which aren't saved to
> - What do all of these do on unknown EAPI?
Again: Why does the API have to care about EAPI? - It's the providers
job to care about it.
> - compare_version. But it takes packages. What's the ordering on
> foo/bar-1 vs bar/baz-1?
Currently it would return: ("bar-1", "baz-1") as bar < baz. But this can
easily specified different. And a good point to think about error
> - get_actual_use_flags. What's the point of this?
In general: Returns all useflags currently set (even the package
specific ones). It additionally has the ability to merge in some other
flag settings. (Ok - the description in the API-document is a little bit
> - get_dep_packages. Hardcoding three dep classes is icky and doesn't
> work nicely with future EAPIs.
Is only hard-coded in the document. (Count this as a doc-error.)
> And what's the return value? What about when || is in operation?
WWPMD (what would the package manager do): Simplified: Pass the
dep-string to the package manager and see what he does with it. The
result is returned.
> - get_iuse_flags. What does this do for IUSE defaults? For installed
> packages, all flags are forced.
defaults are returned verbatim. I used to define "forced flags" as: "The
flags the user can't change." (like userland_GNU or use.mask'ed flags)
> - get_installed_use_flags. Empty list? Seriously?
DBus does not know the "empty value". The signature has to be kept in
all cases. So: yes - empty list. (Other choice would be an exception...)
> - get_masking_reason. Is the return value supposed to be used by
> anything other than a human?
I doubt it.
> - get_matched_dep_packages. Huh?
Return all packages the cpv depends on, but which are already installed.
"get_dep_packages" and "get_matched_dep_packages" can surely be merged.
> - get_overlay_path. What if it's in an overlay with no on-disk location?
> What if it's in some format the end tool doesn't recognise?
The end tool's problem I'd say.
> - get_use_flags. Bad. No legit use.
Doc error. Has already been removed several weeks ago.
> - is_in_system. System is a bad name.
Renaming is easy :)
> - is_testing. How does package.keywords alter whether a package is
Just a naming issue - I use "testing" for things that are keyworded
> - use_expanded. Not clear how this works when things aren't really
Return "". The naming is bad here too.
> or when expanded keys aren't known.
When should that happen?
> Why DBus?
> What's the point in using DBus? What does it add over a simplified
> library with bindings?
Library bindings have several disadvantages:
- - Providers have to be coded in C.
- - How to access portage internals from C-Code? Yes: You can implement
python-calls in C... but I think this is messy.
- - allows some interesting structures: Like dbus+ssh: Contact the
Catapult-Service on one machine from another one (remote adminstration)
- - bindings already provided
- - caching: For example the portage internal caches are kept and don't
have to be recreated each time something using catapult is started.
> How does the whole privs thing work? Should anyone who can talk by DBus
> be allowed to perform privileged operations? Should anyone who can't
> perform privileged operations be allowed to do unprivileged operations?
I thought of having Catapult being a passive thing. So there is no way
of doing privileged actions.
> What about persistence? What's classed as a session? Why force it down
> to a single session at once?
Easier to implement. But it isn't forced. If the provider implements
sessions (e.g. using the Dbus-sending-adress as a key) w/o extending
API, I can't see a problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
email@example.com mailing list