1 |
Detlev, I would continue implementing as much of the pkgcore backend as possible before creating replacements or missing functionality. That will give ferringb a chance to move and possibly offer other ways of doing it. In the meantime use portage for the missing func()'s. |
2 |
|
3 |
Detlev Casanova <detlev.casanova@×××××.com> wrote: |
4 |
|
5 |
>Hello everyone ! |
6 |
> |
7 |
>This week, I almost finished working on the portage_2_2 backend's access |
8 |
>functions. |
9 |
>Thos functions are used to get information on packages and on the environment |
10 |
>from the plugin (in this case, Portage 2.2). |
11 |
>There is an exception for get_property() which currently loads up all |
12 |
>properties for all packages and returns the one asked for. |
13 |
> |
14 |
>The next step for this backend is to implement actions : install, uninstall |
15 |
>and update a package. |
16 |
> |
17 |
>The implementation of those actions in the portage API being not ready yet, |
18 |
>I've also started working on the pkgcore plugin. |
19 |
>Here, I have some troubles as to some functionalities are not present in |
20 |
>pkgcore. Or at least, not accessible. To name a few, versions comparison, hard |
21 |
>masking reason, package size. And I certainly haven't got into other ones. So |
22 |
>the question is : do I use portage API's functions to do this or do I |
23 |
>reimplement those ? |
24 |
> |
25 |
>Another possiblity could be to have functionalities not implemented in a |
26 |
>backend and make porthole aware of it. Messages like "The Pkgcore backend does |
27 |
>not support this feature" would be shown instead of the masking reason. Of |
28 |
>course, functions like version comparison must be implemented. |
29 |
> |
30 |
>The API being a lot different from portage's, I found some functions that |
31 |
>could be simplifyed or even removed, because they where doing something |
32 |
>similar. |
33 |
> |
34 |
>As the project is reworking porthole (and not just interface qith a new |
35 |
>backend system), there will be rework to remove and improve some functions |
36 |
>too. Particularly, the best() methode which compares a list of versions (with |
37 |
>no package name). Pkgcore allows me to compare versions with package name. I |
38 |
>don't see the point in keeping the function that way. |
39 |
> |
40 |
>This week, I'll spend some time on studying for my last exam (Friday) and |
41 |
>continue working on the pkgcore module. |
42 |
> |
43 |
> |
44 |
>Detlev. |