Gentoo Archives: gentoo-guis

From: "René 'Necoro' Neumann" <lists@××××××.eu>
To: gentoo-guis@l.g.o
Subject: Re: [gentoo-guis] One backend for all portage GUIs
Date: Thu, 11 Oct 2007 05:37:24
In Reply to: Re: [gentoo-guis] One backend for all portage GUIs by Brian
Hash: SHA1

Brian schrieb:
> On Wed, 2007-10-10 at 19:47 +0200, René 'Necoro' Neumann wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> René 'Necoro' Neumann schrieb: >> >> Ok - I've added the current API to the wiki [1]. I did not manage to >> include all of the needs of porthole, as I don't know what some of the >> calls do, and whether they are really needed ;). >> Please see the attached file for the comments. >> >> @dol-sen: Would be great if you could scan through the list and see, >> which ones are really needed. Because portage calls inside functions >> that are then moved into catapult don't need to have an equivalent in >> the API (at least in most cases). - And for the vast majority I was just >> clueless ^^. (and too lazy to lookup portage code). > > > Yeah, I know... I made the list only for reference as to the calls to > portage used. To know what they are used for, etc. you need to go thru > portagelib. Many of the ones needed you already have blank defs for and > raise NotImplemented ERROR. I didn't expect you to implement them all > now anyway :) >
Oh oh ... it seems like we are mixing things up here ... Please do not refer to the Portato Code anymore. The only important thing is the catapult code [1] and the API documentation. Sorry if I confused you all =|
> >> There are certain issues with the current API: >> >> 1.) Add some more stuff needed by other frontends. >> 2.) Perhaps merge the Package and the System object as they both just >> provide functions. > > I had a chance to look over your code a little more. I think it would > be less confusing if some of the files and classes were renamed. You've > used and class XXXPackage several times. It gets confusing > with a frontend's Package class... Since they are just function groups > then perhaps > > class CPVFunctions > > Anyway, I have some ideas on how we might organize groups of functions, > but I need more time to think it thru and get them down in print. >
As I said: Ignore portato's code. ;). And the naming of the classes is really arbitrary - we might change this if you want. What is more important is the DBus-Object Path...
>> 3.) Merge package.is_in_overlay() and package.get_overlay_path() >> 4.) Get rid of the different get_*_settings functions and add special >> ones: get_homepage, get_depend(which), get_arch, ... >> 5.) Currently there are two functions returning use flags which were set >> at installation time of a package: >> - get_use_flags(): Returning ALL set useflags >> - get_installed_use_flags(): Return only the set useflags which are >> also in IUSE. >> This should perhaps be merged into one function with an attribute >> "only_iuse" or similar. >> >> Some comments are appreciated ;) >> >> - - Necoro > > Sorry, I have to work again tonight. I won't have time to look yet. > Only enough time to respond with this email. >
- - Necoro [1] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - iD8DBQFHDbQd4UOg/zhYFuARAi4TAJ45M1hT94FiRmxnZZymu9ID5NcYIACeI6ZC KYfWtnM1mPRY5w5YygBc8xs= =1KFQ -----END PGP SIGNATURE----- -- gentoo-guis@g.o mailing list