1 |
On Mon, 2014-01-13 at 15:46 +0100, Tom Wijsman wrote: |
2 |
> On Mon, 13 Jan 2014 16:15:37 +0700 |
3 |
> "C. Bergström" <cbergstrom@×××××××××.com> wrote: |
4 |
> |
5 |
> > Long term the API to pkgcore could be beneficial, but |
6 |
> > again I'm not sure it's a game changer for users. |
7 |
> |
8 |
> Long term, we should have an independent API backend that tools can |
9 |
> query; not rewrite our tools every time users want to use them with a |
10 |
> different package manager. |
11 |
> |
12 |
|
13 |
I have been working towards that for years, but, things keep getting in |
14 |
the way. By things, I mean other project work that needs to be done as |
15 |
well. I got started in all this working on porthole, which uses |
16 |
portage's api for much of it's information. To get more features, |
17 |
information, I wanted to be able to incorporate some of gentoolkit's |
18 |
info. Namely equery, but most of it's working code was embedded with |
19 |
it's output. I worked hard at separating out it's working code from |
20 |
it's output so it would be usable by other tools. I have also been |
21 |
working on making a pkgcore backend for porthole. In doing that it |
22 |
required making a different backend for portage to get some uniformity |
23 |
for the frontend. I have had to put development of those on hold, due |
24 |
to taking over layman's development. I gave it a new high level api, |
25 |
modified it's mid level code and gave it a nice api that can be used by |
26 |
other apps, guis, etc.. One of the things that came up with layman was |
27 |
to be able to gpg enable it to verify it's repositories.xml list it |
28 |
downloads. I did that. In so doing created dev-python/pyGPG a python |
29 |
lib, which has now brought me in to developing Gentoo-keys (another |
30 |
project that could use help) to manage gentoo's gpg release, developer |
31 |
keys, and verification. Also at the same time a year ago, there was a |
32 |
lot of talk about moving the default location of the gentoo tree, but it |
33 |
could not be done with current catalyst code. So offered to help out as |
34 |
that project was severely lacking people with decent python skills. |
35 |
That code base is like what portage code was 8 years ago. And if you |
36 |
thought todays portage code is bad... you would cringe to see it's code |
37 |
from 8 years ago. |
38 |
|
39 |
Now portage was in trouble, while there were some people stepping in to |
40 |
fix things, I stepped up to help drive out a new release. I am now |
41 |
interim lead till we hold an election. So most of my time now is spent |
42 |
steering projects, more than coding. Hey, it's all work that has to be |
43 |
done. So I'm putting out fires where it needs it most. |
44 |
|
45 |
With that aside. One of the biggest hurdles new developers face with |
46 |
pkgcore is the lack of decent api docs and flow charts. Brian was |
47 |
brilliant and OCD about attaining speed, but at the cost of difficulty |
48 |
in following the code and creating the steep learning curve. I have |
49 |
been trying to get these other projects to a point I could create the |
50 |
docs and charts needed so that it would be easier for new developers to |
51 |
find their way in pkgcores code. That is when pkgcore will make more |
52 |
headway at becoming portage's replacement. But some new fires keep |
53 |
popping up. |
54 |
|
55 |
|
56 |
Long story in a nutshell, gentoo could use more GOOD firefighters. |
57 |
|
58 |
Sorry for the long speech ;) |
59 |
your friendly gentoo python firefighter |
60 |
|
61 |
-- |
62 |
Brian Dolbec <dolsen@g.o> |