Gentoo Archives: gentoo-guis

From: "René 'Necoro' Neumann" <lists@××××××.eu>
To: gentoo-guis@l.g.o
Cc: Kuroo Kuroo <kuroo.info@×××××.com>, nirbheek.chauhan@×××××.com, Porthole-Developers <porthole-devel@×××××××××××××××××.net>, info@×××××.org
Subject: Re: [gentoo-guis] One backend for all portage GUIs
Date: Tue, 09 Oct 2007 12:15:39
Message-Id: 470B6E99.1000001@necoro.eu
In Reply to: Re: [gentoo-guis] One backend for all portage GUIs by Brian
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

Replies

Subject Author
Re: [gentoo-guis] One backend for all portage GUIs "René 'Necoro' Neumann" <lists@××××××.eu>