| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
René 'Necoro' Neumann schrieb: |
| 5 |
> Brian schrieb: |
| 6 |
>> On Tue, 2007-09-10 at 23:54 +0200, René 'Necoro' Neumann wrote: |
| 7 |
> |
| 8 |
>>> This is the thing I'm waiting for atm ... the functions to implement (ie |
| 9 |
>>> the API)... I think, that it should be done in a functional way is |
| 10 |
>>> general consensus, isn't it? |
| 11 |
>>> |
| 12 |
>> Ok, I've put together a small list of portage calls mostly unigue, but |
| 13 |
>> many have variations of the basic call (not listed)repeated for |
| 14 |
>> different info returned. A few lines of code I left in to make it more |
| 15 |
>> clear, but should give an overall list of the portage function calls |
| 16 |
>> used so far. |
| 17 |
> |
| 18 |
> |
| 19 |
>> I will put together a list of functions that I created in portagelib to |
| 20 |
>> add functionality directly related to portage. Some of them are copies |
| 21 |
>> of code chunks from lifted from gentoolkit. |
| 22 |
> |
| 23 |
>>> Regards, |
| 24 |
>>> - - Necoro |
| 25 |
> Thanks =) |
| 26 |
> |
| 27 |
> I've put it into the Wiki [1] too. :) |
| 28 |
> |
| 29 |
> I'll try again today to create some API documentation and will merge |
| 30 |
> your requirements. |
| 31 |
|
| 32 |
Ok - I've added the current API to the wiki [1]. I did not manage to |
| 33 |
include all of the needs of porthole, as I don't know what some of the |
| 34 |
calls do, and whether they are really needed ;). |
| 35 |
Please see the attached file for the comments. |
| 36 |
|
| 37 |
@dol-sen: Would be great if you could scan through the list and see, |
| 38 |
which ones are really needed. Because portage calls inside functions |
| 39 |
that are then moved into catapult don't need to have an equivalent in |
| 40 |
the API (at least in most cases). - And for the vast majority I was just |
| 41 |
clueless ^^. (and too lazy to lookup portage code). |
| 42 |
|
| 43 |
There are certain issues with the current API: |
| 44 |
|
| 45 |
1.) Add some more stuff needed by other frontends. |
| 46 |
2.) Perhaps merge the Package and the System object as they both just |
| 47 |
provide functions. |
| 48 |
3.) Merge package.is_in_overlay() and package.get_overlay_path() |
| 49 |
4.) Get rid of the different get_*_settings functions and add special |
| 50 |
ones: get_homepage, get_depend(which), get_arch, ... |
| 51 |
5.) Currently there are two functions returning use flags which were set |
| 52 |
at installation time of a package: |
| 53 |
- get_use_flags(): Returning ALL set useflags |
| 54 |
- get_installed_use_flags(): Return only the set useflags which are |
| 55 |
also in IUSE. |
| 56 |
This should perhaps be merged into one function with an attribute |
| 57 |
"only_iuse" or similar. |
| 58 |
|
| 59 |
Some comments are appreciated ;) |
| 60 |
|
| 61 |
- - Necoro |
| 62 |
|
| 63 |
[1] http://catapult.origo.ethz.ch/wiki/API |
| 64 |
-----BEGIN PGP SIGNATURE----- |
| 65 |
Version: GnuPG v1.4.7 (GNU/Linux) |
| 66 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 67 |
|
| 68 |
iD8DBQFHDRAq4UOg/zhYFuARAmyxAJ4jqUKg8pAIi6AGv/QYcGZ4XOagkACeOFJK |
| 69 |
9XOv2sBduIknjtsKv8CbYqM= |
| 70 |
=1FVU |
| 71 |
-----END PGP SIGNATURE----- |
Archives