1 |
On Mon, 2007-08-10 at 19:52 +0200, René 'Necoro' Neumann wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> > |
6 |
> > At the beginning of next week, I'm planning to make portato use this new |
7 |
> > amazing backend :). We'll see if this is going to work... (Rumors say |
8 |
> > that currently dbus times out on the first connect...) |
9 |
> |
10 |
> As promised, I finished a portato version which is using the new |
11 |
> catapult backend... (Btw - the rumor has been proved being wrong ;)) |
12 |
> |
13 |
> You can get the code doing: |
14 |
> svn co https://svn.origo.ethz.ch/portato/trunk |
15 |
> or you can install portato with catapult support: |
16 |
> 1. layman -o http://portato.sourceforge.net/layman.xml -f |
17 |
> 2. layman -o http://portato.sourceforge.net/layman.xml -a portato |
18 |
> 3. USE="catapult" emerge -av "=portato-9999" |
19 |
> |
20 |
> |
21 |
> Now another question occurs: Am I the only one interested in this |
22 |
> project? Because there is nearly no feedback/suggestions/discussions |
23 |
> (except with bheekling in IRC) |
24 |
> |
25 |
> Regards, |
26 |
> - - Necoro |
27 |
|
28 |
No, I am interested in working with you to develop an (hopefully) |
29 |
universal back-end. Like others have said, I have been busy and not had |
30 |
more time to work on it. I also need to finish some things and a few |
31 |
bug fixes to get a release out. Any new back-end support will need to |
32 |
wait for a future release. |
33 |
|
34 |
|
35 |
I almost sent a reply early this weekend, but you did say you would not |
36 |
be starting until this week and that you wanted to do some testing to |
37 |
prove or debunk some rumours as to it's performance. |
38 |
|
39 |
I am glad that you have been able to debunk them :) |
40 |
|
41 |
Now for some more nitty gritty things. So far we have not |
42 |
discussed/decided which of the models you laid out we would base this |
43 |
new back-end on. So far it is just portato's existing back-end wrapped |
44 |
in dbus. I think it is great for initial testing without expending a |
45 |
lot of effort in restructuring any front-end code. But I do not think |
46 |
it would be usable for me at all. Porthole has grown so much over the |
47 |
years that it's code was getting somewhat like portage's, huge files. |
48 |
For this next version I have spilt things up quite a bit, modularizing |
49 |
things better. Have cut down memory usage quite a bit and sped things |
50 |
up quite a bit in the process. |
51 |
|
52 |
|
53 |
One of the things that I did was to create a separate db module. In the |
54 |
past much of it was incorporated into our portagelib. That makes it |
55 |
more difficult to change back-end, package managers and update code for |
56 |
changes from upstream. So far your catapult back-end is creating a |
57 |
package object for your front-end. That may be fine for a fully |
58 |
integrated program, but now you are separating it out into it's own |
59 |
process and passing that structure to your front-end. I don't know if |
60 |
dbus is passing references (pointers) or making copies. I think that |
61 |
there is potential for large memory leaks that way. Also portholes |
62 |
definition of a package object is different than portato's as I'm sure |
63 |
kuroo's and himerge's is. I believe that the back-end should be |
64 |
restricted to only interfacing the front-end to the package manager |
65 |
enquiries along with some utility code for odds and ends to provide a |
66 |
more complete back-end service. By odds and ends I mean code chunks |
67 |
needed to be able to provide missing features/functions of the different |
68 |
package managers we may support. |
69 |
|
70 |
I think that pothole's potagelib.py contents is more of what a back-end |
71 |
should provide. I'll be the first to admit (I'm biased) it needs work |
72 |
and cleanup and there is room for it to grow/improve. I do not think |
73 |
that it should be providing package structures with embedded package |
74 |
manager calls. I think it should be restricted to the basic data types |
75 |
returned by the package managers. Any more complex structures should be |
76 |
handled by the front-end code or any intermediate code it uses. |
77 |
|
78 |
Anyway... my thoughts so far. How about the others? What do you see as |
79 |
your needs of a back-end? |
80 |
|
81 |
|
82 |
Another question, I have subscribed to the gentoo-guis list. Is |
83 |
everyone else that is interested also? Should we just use that list for |
84 |
now? So I/we don't get 4 or five copies of an email from different |
85 |
directions. |
86 |
|
87 |
As for IRC, I'm not that big on it. Also I'm in the Canada/US Pacific |
88 |
time zone, Necoro I believe is in Europe. That usually means when I'm |
89 |
going to bed, he's just coming online and vice versa. |
90 |
|
91 |
-- |
92 |
Brian <dol-sen@×××××.net> |
93 |
|
94 |
-- |
95 |
gentoo-guis@g.o mailing list |