1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Brian wrote: |
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 |
> One of the things that I did was to create a separate db module. In the |
31 |
> past much of it was incorporated into our portagelib. That makes it |
32 |
> more difficult to change back-end, package managers and update code for |
33 |
> changes from upstream. So far your catapult back-end is creating a |
34 |
> package object for your front-end. That may be fine for a fully |
35 |
> integrated program, but now you are separating it out into it's own |
36 |
> process and passing that structure to your front-end. I don't know if |
37 |
> dbus is passing references (pointers) or making copies. I think that |
38 |
> there is potential for large memory leaks that way. Also portholes |
39 |
> definition of a package object is different than portato's as I'm sure |
40 |
> kuroo's and himerge's is. I believe that the back-end should be |
41 |
> restricted to only interfacing the front-end to the package manager |
42 |
> enquiries along with some utility code for odds and ends to provide a |
43 |
> more complete back-end service. By odds and ends I mean code chunks |
44 |
> needed to be able to provide missing features/functions of the different |
45 |
> package managers we may support. |
46 |
> |
47 |
|
48 |
That's right, different front-ends have different package object |
49 |
representation. One of my idea was to write an initial library (probably |
50 |
on C so it can easily be used through many languages) , creating a set |
51 |
of sharable procedures between front-ends, this also could give us some |
52 |
ideas of how far a general package object representation is possible |
53 |
between the different front-ends ; i think that'd be a good way to start |
54 |
building this project. |
55 |
|
56 |
> I think that pothole's potagelib.py contents is more of what a back-end |
57 |
> should provide. I'll be the first to admit (I'm biased) it needs work |
58 |
> and cleanup and there is room for it to grow/improve. I do not think |
59 |
> that it should be providing package structures with embedded package |
60 |
> manager calls. I think it should be restricted to the basic data types |
61 |
> returned by the package managers. Any more complex structures should be |
62 |
> handled by the front-end code or any intermediate code it uses. |
63 |
> |
64 |
|
65 |
Right, I also agree that this back-end should only generate general data |
66 |
that can be easily shared by many front-ends so they can handle these |
67 |
objects in whatever way fits better for each one. Now, the question is, |
68 |
what kind of data exactly would this be?, it's here where i think the |
69 |
library project would help to figure this out. But as to give an initial |
70 |
idea, this library could be usable by any kind of portage front-end (no |
71 |
only graphical) and should be easily used through different tools. |
72 |
|
73 |
> Anyway... my thoughts so far. How about the others? What do you see as |
74 |
> your needs of a back-end? |
75 |
> |
76 |
> |
77 |
> Another question, I have subscribed to the gentoo-guis list. Is |
78 |
> everyone else that is interested also? Should we just use that list for |
79 |
> now? So I/we don't get 4 or five copies of an email from different |
80 |
> directions. |
81 |
> |
82 |
|
83 |
Yes, We are using this mailing list to discuss this project, so, anyone |
84 |
interested on this subject, please subscribe to it. |
85 |
|
86 |
> As for IRC, I'm not that big on it. Also I'm in the Canada/US Pacific |
87 |
> time zone, Necoro I believe is in Europe. That usually means when I'm |
88 |
> going to bed, he's just coming online and vice versa. |
89 |
> |
90 |
|
91 |
Don't worry about that, everyone is spread around the globe, if you have |
92 |
some time, try to stop by it too and say hi :-) |
93 |
|
94 |
Regards, |
95 |
|
96 |
- -- |
97 |
|
98 |
Luis F. Araujo "araujo at gentoo.org" |
99 |
Gentoo Linux |
100 |
|
101 |
-----BEGIN PGP SIGNATURE----- |
102 |
Version: GnuPG v2.0.7 (GNU/Linux) |
103 |
|
104 |
iD8DBQFHC/OVBCmRZan6aegRAh0OAJ0Y5Md+nl+B8z7v0iwUnzJWWtVw1ACgsySa |
105 |
cUbTLZn4gUV6r0/NOW/56KM= |
106 |
=YfPV |
107 |
-----END PGP SIGNATURE----- |
108 |
-- |
109 |
gentoo-guis@g.o mailing list |