Gentoo Archives: gentoo-guis

From: Brian <dol-sen@×××××.net>
To: "René 'Necoro' Neumann" <lists@××××××.eu>
Cc: gentoo-guis@l.g.o, Kuroo Kuroo <kuroo.info@×××××.com>, nirbheek.chauhan@×××××.com, Luis Francisco Araujo <araujo@g.o>, Porthole-Developers <porthole-devel@×××××××××××××××××.net>, info@×××××.org
Subject: Re: [gentoo-guis] One backend for all portage GUIs
Date: Tue, 09 Oct 2007 06:54:08
Message-Id: 1191912347.12008.88.camel@localhost
In Reply to: Re: [gentoo-guis] One backend for alle portage GUIs by "René 'Necoro' Neumann"
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

Replies

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