1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Brian schrieb: |
5 |
> On Mon, 2007-08-10 at 19:52 +0200, René 'Necoro' Neumann wrote: |
6 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
7 |
>> Hash: SHA1 |
8 |
>> |
9 |
>>> At the beginning of next week, I'm planning to make portato use this new |
10 |
>>> amazing backend :). We'll see if this is going to work... (Rumors say |
11 |
>>> that currently dbus times out on the first connect...) |
12 |
>> As promised, I finished a portato version which is using the new |
13 |
>> catapult backend... (Btw - the rumor has been proved being wrong ;)) |
14 |
>> |
15 |
>> You can get the code doing: |
16 |
>> svn co https://svn.origo.ethz.ch/portato/trunk |
17 |
>> or you can install portato with catapult support: |
18 |
>> 1. layman -o http://portato.sourceforge.net/layman.xml -f |
19 |
>> 2. layman -o http://portato.sourceforge.net/layman.xml -a portato |
20 |
>> 3. USE="catapult" emerge -av "=portato-9999" |
21 |
>> |
22 |
>> |
23 |
>> Now another question occurs: Am I the only one interested in this |
24 |
>> project? Because there is nearly no feedback/suggestions/discussions |
25 |
>> (except with bheekling in IRC) |
26 |
>> |
27 |
>> Regards, |
28 |
>> - - Necoro |
29 |
> |
30 |
> No, I am interested in working with you to develop an (hopefully) |
31 |
> universal back-end. Like others have said, I have been busy and not had |
32 |
> more time to work on it. I also need to finish some things and a few |
33 |
> bug fixes to get a release out. Any new back-end support will need to |
34 |
> wait for a future release. |
35 |
|
36 |
Yeah - sorry me =| ... I've been a little too impatient :) |
37 |
> |
38 |
> |
39 |
> I almost sent a reply early this weekend, but you did say you would not |
40 |
> be starting until this week and that you wanted to do some testing to |
41 |
> prove or debunk some rumours as to it's performance. |
42 |
> |
43 |
> I am glad that you have been able to debunk them :) |
44 |
> |
45 |
> Now for some more nitty gritty things. So far we have not |
46 |
> discussed/decided which of the models you laid out we would base this |
47 |
> new back-end on. |
48 |
We decided (where "we" means: bheekling, araujo and me) to use (try?) |
49 |
the structure mentioned here [1] as "No Daemon". |
50 |
|
51 |
> So far it is just portato's existing back-end wrapped |
52 |
> in dbus. I think it is great for initial testing without expending a |
53 |
> lot of effort in restructuring any front-end code. But I do not think |
54 |
> it would be usable for me at all. Porthole has grown so much over the |
55 |
> years that it's code was getting somewhat like portage's, huge files. |
56 |
> For this next version I have spilt things up quite a bit, modularizing |
57 |
> things better. Have cut down memory usage quite a bit and sped things |
58 |
> up quite a bit in the process. |
59 |
> |
60 |
> |
61 |
> So far your catapult back-end is creating a |
62 |
> package object for your front-end. |
63 |
Wrong... basically the "Package" and "System" classes are just a bunch |
64 |
of functions. They do not behave in an object-oriented manner (ie. you |
65 |
have to provide a CPV (cat/pkg-ver) for each call to the Package |
66 |
object). So this really is functional. Perhaps they can be merged into |
67 |
one object - just wanted to structurize a little bit. |
68 |
I thought of doing it really object-oriented, i.e. creating a |
69 |
dbus-object for each package in the tree (so you would then have for |
70 |
example: "org/gentoo/catapult/packages/sys-apps/portage") but this kinda |
71 |
screwed up dbus ;). |
72 |
|
73 |
Portato (which supported switching backends for some time already) is |
74 |
wrapping these functional calls into its own objects... see the |
75 |
CatapultPackage object [2] as an example. |
76 |
|
77 |
> That may be fine for a fully |
78 |
> integrated program, but now you are separating it out into it's own |
79 |
> process and passing that structure to your front-end. I don't know if |
80 |
> dbus is passing references (pointers) or making copies. I think that |
81 |
> there is potential for large memory leaks that way. Also portholes |
82 |
> definition of a package object is different than portato's as I'm sure |
83 |
> kuroo's and himerge's is. |
84 |
Does not apply -- see above :) |
85 |
|
86 |
> I believe that the back-end should be |
87 |
> restricted to only interfacing the front-end to the package manager |
88 |
> enquiries along with some utility code for odds and ends to provide a |
89 |
> more complete back-end service. By odds and ends I mean code chunks |
90 |
> needed to be able to provide missing features/functions of the different |
91 |
> package managers we may support. |
92 |
|
93 |
Yes - this is what we want to achieve. |
94 |
What we need is a stable API - so that we can say: All backends have to |
95 |
provide the following functions: ... |
96 |
|
97 |
> |
98 |
> I think that pothole's potagelib.py contents is more of what a back-end |
99 |
> should provide. I'll be the first to admit (I'm biased) it needs work |
100 |
> and cleanup and there is room for it to grow/improve. I do not think |
101 |
> that it should be providing package structures with embedded package |
102 |
> manager calls. I think it should be restricted to the basic data types |
103 |
> returned by the package managers. Any more complex structures should be |
104 |
> handled by the front-end code or any intermediate code it uses. |
105 |
|
106 |
See 3 above ;) |
107 |
|
108 |
> Anyway... my thoughts so far. How about the others? What do you see as |
109 |
> your needs of a back-end? |
110 |
> |
111 |
> |
112 |
> Another question, I have subscribed to the gentoo-guis list. Is |
113 |
> everyone else that is interested also? Should we just use that list for |
114 |
> now? So I/we don't get 4 or five copies of an email from different |
115 |
> directions. |
116 |
|
117 |
I already removed you from the CC list. Should the Portato-Developers be |
118 |
removed too? |
119 |
|
120 |
> |
121 |
> As for IRC, I'm not that big on it. Also I'm in the Canada/US Pacific |
122 |
> time zone, Necoro I believe is in Europe. That usually means when I'm |
123 |
> going to bed, he's just coming online and vice versa. |
124 |
> |
125 |
*stabs the freaking timezones* |
126 |
|
127 |
Regards, |
128 |
- - Necoro |
129 |
|
130 |
[1] http://catapult.origo.ethz.ch/wiki/structure |
131 |
[2] |
132 |
http://svn.origo.ethz.ch/wsvn/portato/trunk/portato/backend/catapult/package.py |
133 |
-----BEGIN PGP SIGNATURE----- |
134 |
Version: GnuPG v1.4.7 (GNU/Linux) |
135 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
136 |
|
137 |
iD8DBQFHC26Z4UOg/zhYFuARArXYAJ47EhHSWgynsdsDzYPc+XBGOvedPQCghYQj |
138 |
10G/yRYmYS0Ukd1Q+wAYEDo= |
139 |
=0TFY |
140 |
-----END PGP SIGNATURE----- |
141 |
-- |
142 |
gentoo-guis@g.o mailing list |