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: gentoo-guis@g.o
From: Luis Francisco Araujo <araujo@g.o>
Subject: Re: One backend for all portage GUIs
Date: Tue, 09 Oct 2007 17:33:09 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian wrote:
> 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
> 
> 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.
> 

That's right, different front-ends have different package object
representation. One of my idea was to write an initial library (probably
on C so it can easily be used through many languages) , creating a set
of sharable procedures between front-ends, this also could give us some
ideas of how far a general package object representation is possible
between the different front-ends ; i think that'd be a good way to start
building this project.

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

Right, I also agree that this back-end should only generate general data
that can be easily shared by many front-ends so they can handle these
objects in whatever way fits better for each one. Now, the question is,
what kind of data exactly would this be?, it's here where i think the
library project would help to figure this out. But as to give an initial
idea, this library could be usable by any kind of portage front-end (no
only graphical) and should be easily used through different tools.

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

Yes, We are using this mailing list to discuss this project, so, anyone
interested on this subject, please subscribe to it.

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

Don't worry about that, everyone is spread around the globe, if you have
some time, try to stop by it too and say hi :-)

Regards,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHC/OVBCmRZan6aegRAh0OAJ0Y5Md+nl+B8z7v0iwUnzJWWtVw1ACgsySa
cUbTLZn4gUV6r0/NOW/56KM=
=YfPV
-----END PGP SIGNATURE-----
-- 
gentoo-guis@g.o mailing list


Replies:
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
Re: One backend for all portage GUIs
-- Brian
Navigation:
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: One backend for all portage GUIs
Next by thread:
Re: One backend for all portage GUIs
Previous by date:
Re: One backend for all 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.