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
Lists: gentoo-guis: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-guis@g.o
From: René 'Necoro' Neumann <lists@...>
Subject: Re: One backend for alle portage GUIs
Date: Thu, 20 Sep 2007 21:14:03 -0700
Hash: SHA1

Just to bring some new better terms:
- - backend: is the whole thing which has to be written
- - provider: the part between backend and package manager

Luis Francisco Araujo schrieb:
> René 'Necoro' Neumann wrote:
>> While thinking about it, I wondered, why we have so many different
>> portage frontends - and each having its own portage backend. As there
>> are different approaches in defining a GUI, there is only one approach
>> of getting your information from portage. So instead of having one GUI,
> It might theoretically sound like that , but different GUI approaches
> might bring different backend approaches too.

Ok - I only thought about the object oriented approach. That is true.
>> I want to have one backend, which can be used by all different GUIs.
>> This makes the development of new GUIs simple - and might even be useful
>> for small scripts.
>> Also this backend should it make possible to access different package
>> managers (portage, paludis, pkgcore, equo) through one standardized API.
>> Thus in the end all GUIs will support all different Gentoo Package Manglers.
> It really sounds nice, i suppose it'd be a matter of defining what would
> be the exact scope of this back-end. I don't think it might offer all
> the necessary stuff for different package managers to make truly
> independent a GUI from back-end code , nevertheless , it could really
> offer a set of sharable standard procedures (probably as a library?).

Hmm ... this has to be defined. I don't know in detail what are the
differences between the package managers. But I think all of them extend
portage in a way. So one could agree on defining portage as the basic
set of operations supported - and everything else has to be implemented
by the GUI itself.

>> HOW?
>> ====
>> Basically I want to have one service in the middle, that is accessed via
>> DBus. This service itself calls pkg-manager backends which in turn get
>> information out of the pkg manager.
>> For the second part there are two different approaches:
>> 1) Have all backends in the service itself.
> This would be pretty much like a library, there is no need for DBus in
> such a case i think.

The library still has the problem that you have to find a common
demoninator as the language to write the library in... (And it produces
some overhead, as you have to access portage using C for example).

Ok ... you could write e.g. the portage provider in Python and put a
small C layer on top to have the normal bindings...

>> 2)
>> - P: Different languages can be chosen - and it is easy to add a new
>> backend.
> This makes a more proper usage of DBus i suppose ; 
I would still prefer this way - if Dbus hadn't some open issues like

> nevertheless here we
> could face the problem of DBus not getting or handling languages
> features the programmer would like to take advantage of
You and your Haskell ;P --- but you are true: DBus is object oriented

> this also would involve creating different sub-sets of API for each language to
> circumvent some of these issues ... and the thing might get more complex.... 
no - there would be still be one single API ... the GUI itself then had
to map it to get the way it wants it to be

>> - P: The backend might be provided by the package manager itself, which
>> makes it easier to maintain.
> The package manager or the GUI front-end?, if its the former, we would
> have to talk the different package managers developers into this , and
> if it is the later, .... it's pretty much what all the GUI front-ends
> are already doing i guess.

I meant the "backend providers" for the service to be maintained by the
normal package managers.

- - Nec

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

gentoo-guis@g.o mailing list

One backend for alle portage GUIs
-- René 'Necoro' Neumann
Re: One backend for alle portage GUIs
-- Luis Francisco Araujo
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 alle portage GUIs
Previous by date:
Re: One backend for alle portage GUIs
Next by date:
Re: One backend for alle 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.