Gentoo Archives: gentoo-guis

From: Luis Francisco Araujo <araujo@g.o>
To: gentoo-guis@l.g.o
Subject: Re: [gentoo-guis] One backend for all portage GUIs
Date: Tue, 09 Oct 2007 21:50:16
Message-Id: 470BF395.5030104@gentoo.org
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 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

Replies

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