Gentoo Archives: gentoo-guis

From: "René 'Necoro' Neumann" <lists@××××××.eu>
To: ciaran.mccreesh@××××××××××.com
Cc: gentoo-guis@l.g.o
Subject: Re: [gentoo-guis] Why I don't like catapult
Date: Sun, 30 Mar 2008 17:30:36
In Reply to: [gentoo-guis] Why I don't like catapult by Ciaran McCreesh
Hash: SHA1

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 the future.
> * 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?
Undefined atm.
> 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 > configuration.
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 > merge?
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 > --install?
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 configs yet.)
> - 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 handling again.
> - 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 ... strange).
> - 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 > testing?
Just a naming issue - I use "testing" for things that are keyworded "~KEYWORD".
> - use_expanded. Not clear how this works when things aren't really > expanded.
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. Dbus advantages: - - 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. Regards, Necoro -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - iD4DBQFH784w4UOg/zhYFuARAnZRAJ4hnjiH/2yycAiDCXLnst2EpesyuQCWJNNs 6gPL9qWeiaFgCGzpwbT9cA== =Pdi+ -----END PGP SIGNATURE----- -- gentoo-guis@l.g.o mailing list


Subject Author
Re: [gentoo-guis] Why I don't like catapult Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>