Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-guis
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: "René 'Necoro' Neumann" <lists@...>
From: Brian <dol-sen@...>
Subject: Re: One backend for all portage GUIs
Date: Mon, 08 Oct 2007 23:45:47 -0700
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)
> 
> Regards,
> - - 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.


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.  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.


One of the things that I did was to create a separate db module. In the
past much of it was incorporated into our portagelib.  That makes it
more difficult to change back-end, package managers and update code for
changes from upstream.  So far your catapult back-end is creating a
package object for your front-end.  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.  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.

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.

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
directions.

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.

-- 
Brian <dol-sen@...>

-- 
gentoo-guis@g.o mailing list


Replies:
Re: One backend for all portage GUIs
-- Luis Francisco Araujo
Re: One backend for all portage GUIs
-- René 'Necoro' Neumann
References:
One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- René 'Necoro' Neumann
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: One backend for alle portage GUIs
Next by thread:
Re: One backend for all portage GUIs
Previous by date:
Re: One backend for alle portage GUIs
Next by date:
Re: One backend for all portage GUIs


Updated Jun 17, 2009

Summary: Archive of the gentoo-guis mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.