List Archive: gentoo-guis
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
-----BEGIN PGP SIGNED MESSAGE-----
> On Mon, 2007-08-10 at 19:52 +0200, René 'Necoro' Neumann wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>> At the beginning of next week, I'm planning to make portato use this new
>>> amazing backend :). We'll see if this is going to work... (Rumors say
>>> that currently dbus times out on the first connect...)
>> As promised, I finished a portato version which is using the new
>> catapult backend... (Btw - the rumor has been proved being wrong ;))
>> You can get the code doing:
>> svn co https://svn.origo.ethz.ch/portato/trunk
>> or you can install portato with catapult support:
>> 1. layman -o http://portato.sourceforge.net/layman.xml -f
>> 2. layman -o http://portato.sourceforge.net/layman.xml -a portato
>> 3. USE="catapult" emerge -av "=portato-9999"
>> Now another question occurs: Am I the only one interested in this
>> project? Because there is nearly no feedback/suggestions/discussions
>> (except with bheekling in IRC)
>> - - Necoro
> No, I am interested in working with you to develop an (hopefully)
> universal back-end. Like others have said, I have been busy and not had
> more time to work on it. I also need to finish some things and a few
> bug fixes to get a release out. Any new back-end support will need to
> wait for a future release.
Yeah - sorry me =| ... I've been a little too impatient :)
> I almost sent a reply early this weekend, but you did say you would not
> be starting until this week and that you wanted to do some testing to
> prove or debunk some rumours as to it's performance.
> I am glad that you have been able to debunk them :)
> Now for some more nitty gritty things. So far we have not
> discussed/decided which of the models you laid out we would base this
> new back-end on.
We decided (where "we" means: bheekling, araujo and me) to use (try?)
the structure mentioned here  as "No Daemon".
> So far it is just portato's existing back-end wrapped
> in dbus. I think it is great for initial testing without expending a
> lot of effort in restructuring any front-end code. But I do not think
> it would be usable for me at all. Porthole has grown so much over the
> years that it's code was getting somewhat like portage's, huge files.
> For this next version I have spilt things up quite a bit, modularizing
> things better. Have cut down memory usage quite a bit and sped things
> up quite a bit in the process.
> So far your catapult back-end is creating a
> package object for your front-end.
Wrong... basically the "Package" and "System" classes are just a bunch
of functions. They do not behave in an object-oriented manner (ie. you
have to provide a CPV (cat/pkg-ver) for each call to the Package
object). So this really is functional. Perhaps they can be merged into
one object - just wanted to structurize a little bit.
I thought of doing it really object-oriented, i.e. creating a
dbus-object for each package in the tree (so you would then have for
example: "org/gentoo/catapult/packages/sys-apps/portage") but this kinda
screwed up dbus ;).
Portato (which supported switching backends for some time already) is
wrapping these functional calls into its own objects... see the
CatapultPackage object  as an example.
> That may be fine for a fully
> integrated program, but now you are separating it out into it's own
> process and passing that structure to your front-end. I don't know if
> dbus is passing references (pointers) or making copies. I think that
> there is potential for large memory leaks that way. Also portholes
> definition of a package object is different than portato's as I'm sure
> kuroo's and himerge's is.
Does not apply -- see above :)
> I believe that the back-end should be
> restricted to only interfacing the front-end to the package manager
> enquiries along with some utility code for odds and ends to provide a
> more complete back-end service. By odds and ends I mean code chunks
> needed to be able to provide missing features/functions of the different
> package managers we may support.
Yes - this is what we want to achieve.
What we need is a stable API - so that we can say: All backends have to
provide the following functions: ...
> I think that pothole's potagelib.py contents is more of what a back-end
> should provide. I'll be the first to admit (I'm biased) it needs work
> and cleanup and there is room for it to grow/improve. I do not think
> that it should be providing package structures with embedded package
> manager calls. I think it should be restricted to the basic data types
> returned by the package managers. Any more complex structures should be
> handled by the front-end code or any intermediate code it uses.
See 3 above ;)
> Anyway... my thoughts so far. How about the others? What do you see as
> your needs of a back-end?
> Another question, I have subscribed to the gentoo-guis list. Is
> everyone else that is interested also? Should we just use that list for
> now? So I/we don't get 4 or five copies of an email from different
I already removed you from the CC list. Should the Portato-Developers be
> As for IRC, I'm not that big on it. Also I'm in the Canada/US Pacific
> time zone, Necoro I believe is in Europe. That usually means when I'm
> going to bed, he's just coming online and vice versa.
*stabs the freaking timezones*
- - Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
firstname.lastname@example.org mailing list