[gentoo-soc] Rework Porthole to use the new public portage API -- Weekly report #4

[gentoo-soc] Rework Porthole to use the new public portage API -- Weekly report #4

[Detlev Casanova]

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Hello everyone !

This week, I almost finished working on the portage_2_2 backend's access 
functions.
Thos functions are used to get information on packages and on the environment 
from the plugin (in this case, Portage 2.2).
There is an exception for get_property() which currently loads up all 
properties for all packages and returns the one asked for.

The next step for this backend is to implement actions : install, uninstall 
and update a package.

The implementation of those actions in the portage API being not ready yet, 
I've also started working on the pkgcore plugin.
Here, I have some troubles as to some functionalities are not present in 
pkgcore. Or at least, not accessible. To name a few, versions comparison, hard 
masking reason, package size. And I certainly haven't got into other ones. So 
the question is : do I use portage API's functions to do this or do I 
reimplement those ?

Another possiblity could be to have functionalities not implemented in a 
backend and make porthole aware of it. Messages like "The Pkgcore backend does 
not support this feature" would be shown instead of the masking reason. Of 
course, functions like version comparison must be implemented.

The API being a lot different from portage's, I found some functions that 
could be simplifyed or even removed, because they where doing something 
similar.

As the project is reworking porthole (and not just interface qith a new 
backend system), there will be rework to remove and improve some functions 
too. Particularly, the best() methode which compares a list of versions (with 
no package name). Pkgcore allows me to compare versions with package name. I 
don't see the point in keeping the function that way.

This week, I'll spend some time on studying for my last exam (Friday) and 
continue working on the pkgcore module.


Detlev.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-soc] Rework Porthole to use the new public portage API -- Weekly report #4

[Brian Dolbec]

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.

Detlev Casanova <detlev.casanova@gmail.com> wrote:

>Hello everyone !
>
>This week, I almost finished working on the portage_2_2 backend's access 
>functions.
>Thos functions are used to get information on packages and on the environment 
>from the plugin (in this case, Portage 2.2).
>There is an exception for get_property() which currently loads up all 
>properties for all packages and returns the one asked for.
>
>The next step for this backend is to implement actions : install, uninstall 
>and update a package.
>
>The implementation of those actions in the portage API being not ready yet, 
>I've also started working on the pkgcore plugin.
>Here, I have some troubles as to some functionalities are not present in 
>pkgcore. Or at least, not accessible. To name a few, versions comparison, hard 
>masking reason, package size. And I certainly haven't got into other ones. So 
>the question is : do I use portage API's functions to do this or do I 
>reimplement those ?
>
>Another possiblity could be to have functionalities not implemented in a 
>backend and make porthole aware of it. Messages like "The Pkgcore backend does 
>not support this feature" would be shown instead of the masking reason. Of 
>course, functions like version comparison must be implemented.
>
>The API being a lot different from portage's, I found some functions that 
>could be simplifyed or even removed, because they where doing something 
>similar.
>
>As the project is reworking porthole (and not just interface qith a new 
>backend system), there will be rework to remove and improve some functions 
>too. Particularly, the best() methode which compares a list of versions (with 
>no package name). Pkgcore allows me to compare versions with package name. I 
>don't see the point in keeping the function that way.
>
>This week, I'll spend some time on studying for my last exam (Friday) and 
>continue working on the pkgcore module.
>
>
>Detlev.