| 1 |
On Wed, 2012-04-04 at 19:16 +0900, Ryuichi KAWAMATA wrote: |
| 2 |
> Hello! |
| 3 |
> |
| 4 |
> > The best way to keep portato going is to update it's use of portage. |
| 5 |
> > One of the best ways to do that is to finish the new public_api and |
| 6 |
> > change portato to use it. It at the very least needs the current code |
| 7 |
> > updated to the current portage api. |
| 8 |
> Is this means bugs.gentoo.org #136932? |
| 9 |
|
| 10 |
That is an old bug, but essentially, yes. The aim of the public API is |
| 11 |
to have a consistent higher level api for consumer apps/giu's to use for |
| 12 |
gathering data and merging/unmerging pkgs. |
| 13 |
|
| 14 |
|
| 15 |
> I checkout "public_api" branch and merge into "master" branch to try. |
| 16 |
|
| 17 |
There is no need to merge, I will update it again. It also is likely to |
| 18 |
remain installable as a separate ebuild for some time before it is |
| 19 |
merged back into portage master. None of the public_api code changes |
| 20 |
any code within portage's existing code. If there are any changes that |
| 21 |
need to be made, they will likely be merged on an as needed basis. |
| 22 |
|
| 23 |
|
| 24 |
> |
| 25 |
> > For tags support, there are also 2 indexed search utilities used by |
| 26 |
> > users, eix and esearch. Also gentoolkit,s equery could also benefit |
| 27 |
> > from tags support for it's searches. Eix being c++ and both esearch and |
| 28 |
> > equery being python based. |
| 29 |
> > |
| 30 |
> > You should consider those as part of the work for tags support project. |
| 31 |
> I think public_api will solve this problem. |
| 32 |
> |
| 33 |
> I thought the schedule the idea, "Tags support for Portage" is; |
| 34 |
> 1. Implement tags support for Portage |
| 35 |
> 2. Implement public_api for portage that cover all |
| 36 |
> 3. Implement eix, esearch and equery that use public_api which has |
| 37 |
> been implemented in "2." |
| 38 |
> |
| 39 |
|
| 40 |
eix is not python based and does not use portage at all for gathering |
| 41 |
it's data. So making eix use portage is very likely not going to |
| 42 |
happen. There has been a "c" interface started to the public API but |
| 43 |
converting eix to use an updated and hopefully complete new public API |
| 44 |
to portage is not something in the scope of this project. However |
| 45 |
extending eix to support tags with it's current structure and code could |
| 46 |
be. That would need to be worked out with the eix developers. |
| 47 |
|
| 48 |
esearch and equery both use portage for data, so adding tags support to |
| 49 |
them using the portage tags code is certainly something that should be |
| 50 |
considered. |
| 51 |
|
| 52 |
> If all milestones would have been implemented, to use Portage's |
| 53 |
> function by other tools. |
| 54 |
> |
| 55 |
> How about this idea? |
| 56 |
> |
| 57 |
> Please point out :) |
| 58 |
> |
| 59 |
> Thanks. |
| 60 |
> |
| 61 |
|
| 62 |
|
| 63 |
-- |
| 64 |
Brian Dolbec <dolsen@g.o> |
Archives