[gentoo-soc] Graphical portage front-end

[gentoo-soc] Graphical portage front-end

[xqyz]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

Hello,
I would be interested in coding a new and improved graphical front-end for
portage, similar to the old Kuroo Project. The reason why I want to start
from scratch is that I'm not particular inclined to use QT as a toolkit, nor
would I consider CPP my language of choice.
Personally, I would prefer to go with a combination of Python and wxWidgets
on this project. For one thing, performance should allow to switch to Python
without too much speed-loss, and I also think using Python instead of CPP
could attract more non-professional, casual coders to contribute to the
project.
Of course the new application should support similar features as Kuroo did
and improve in some areas. For example I would really like to have an easy
to switch between different compiling settings. By this I mean for example
adjusting distcc to your current environment on you laptop, which is
something I've been looking for for some time now myself. Also it would
provide an easy way for users to find out about new FEATURES settings (eg.
ccache) and install and configure those if needed.
As the wiki stated, I think having a graphical front-end would improve
usability for newer users, while still offering advanced functionality often
missed by more advanced users.
-- Patrick Lerner

[-- Attachment #2: Type: text/html, Size: 1320 bytes --]

Re: [gentoo-soc] Graphical portage front-end

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

On 03/20/2010 12:05 PM, xqyz wrote:
> Hello,
> I would be interested in coding a new and improved graphical front-end
> for portage, similar to the old Kuroo Project. The reason why I want to
> start from scratch is that I'm not particular inclined to use QT as a
> toolkit, nor would I consider CPP my language of choice.

Last year we had a project for PackageKit integration that was never
integrated into the main tree. I would rather continue that work and
then any PackageKit GUI could be used with Portage.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-soc] Graphical portage front-end

[xqyz]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On 20 March 2010 11:16, Petteri Räty <betelgeuse@gentoo.org> wrote:

> Last year we had a project for PackageKit integration that was never
> integrated into the main tree. I would rather continue that work and
> then any PackageKit GUI could be used with Portage.
>

I agree, it would indeed be nice to have a portage integration in
PackageKit, but given the rather unique way of handling packages in Gentoo,
I would consider PackageKit to be a rather poor choice for a package
manager.
USE flags, inability to resolve circular dependencies properly and of course
the advanced compile configuration that Gentoo offers are hard, if not
impossible to be handled by PackageKit. Which is why I think that, even if
there was a working integration of portage, it would not be used much. The
problem with Gentoo is that it more often than not requires the users to
make a choice instead of just settling for a package and clicking install.

--Patrick Lerner

[-- Attachment #2: Type: text/html, Size: 1264 bytes --]

Re: [gentoo-soc] Graphical portage front-end

[Auke Booij]

First things first, I would not know why someone should be using a
graphical installer instead of xterm or one of its colleagues.

Anyway, the problems you are pointing out are exactly what you're
sacrificing by using a GUI, and exactly the reason Gentoo doesn't have
a graphical installer (or one that you should be using, anyway). A lot
of Portage's configuration consists of bash scripts, and any attempt
to fully reproduce their capabilities in a GUI would lead to a big
mess (point-and-click programming, *sigh*). If someone desperately
wants a GUI, it would be for daily Portage activities, and definitely
not for obscure feature x or y.

Further, resolving dependencies is, in my opinion, outside the scope
of a GUI. Functionality that isn't present in the command-line version
of some program shouldn't be added just for the GUI version.

That said, I'm sure some people would love a GUI integration of
different package management tools (ie. search, install, sync...) into
one big package, and it would definitely be a nice improvement to
Sabayon.

tulcod.

On Sat, Mar 20, 2010 at 12:25 PM, xqyz <xqyzii@gmail.com> wrote:
> On 20 March 2010 11:16, Petteri Räty <betelgeuse@gentoo.org> wrote:
>>
>> Last year we had a project for PackageKit integration that was never
>> integrated into the main tree. I would rather continue that work and
>> then any PackageKit GUI could be used with Portage.
>
> I agree, it would indeed be nice to have a portage integration in
> PackageKit, but given the rather unique way of handling packages in Gentoo,
> I would consider PackageKit to be a rather poor choice for a package
> manager.
> USE flags, inability to resolve circular dependencies properly and of course
> the advanced compile configuration that Gentoo offers are hard, if not
> impossible to be handled by PackageKit. Which is why I think that, even if
> there was a working integration of portage, it would not be used much. The
> problem with Gentoo is that it more often than not requires the users to
> make a choice instead of just settling for a package and clicking install.
>
> --Patrick Lerner
>

Re: [gentoo-soc] Graphical portage front-end

[Eric Thibodeau]

In short, I agree with Tucold. Some sort of X-independant but aware (thinking curses here) front end to portage + glsa-checks + ability to select another install root (and throw in neworked eclean while at it) come to mind... I could see this as a useful front end to portage for, ie: managing multiple system images on say, the master node of a cluster ;) If one wants to be really neat feature to such an interface, the ability to install the same package onto multiple roots simultaneously.

...my 2c.

Eric Thibodeau

On 2010-03-20, at 7:44 AM, Auke Booij wrote:

> First things first, I would not know why someone should be using a
> graphical installer instead of xterm or one of its colleagues.
> 
> Anyway, the problems you are pointing out are exactly what you're
> sacrificing by using a GUI, and exactly the reason Gentoo doesn't have
> a graphical installer (or one that you should be using, anyway). A lot
> of Portage's configuration consists of bash scripts, and any attempt
> to fully reproduce their capabilities in a GUI would lead to a big
> mess (point-and-click programming, *sigh*). If someone desperately
> wants a GUI, it would be for daily Portage activities, and definitely
> not for obscure feature x or y.
> 
> Further, resolving dependencies is, in my opinion, outside the scope
> of a GUI. Functionality that isn't present in the command-line version
> of some program shouldn't be added just for the GUI version.
> 
> That said, I'm sure some people would love a GUI integration of
> different package management tools (ie. search, install, sync...) into
> one big package, and it would definitely be a nice improvement to
> Sabayon.
> 
> tulcod.
> 
> On Sat, Mar 20, 2010 at 12:25 PM, xqyz <xqyzii@gmail.com> wrote:
>> On 20 March 2010 11:16, Petteri Räty <betelgeuse@gentoo.org> wrote:
>>> 
>>> Last year we had a project for PackageKit integration that was never
>>> integrated into the main tree. I would rather continue that work and
>>> then any PackageKit GUI could be used with Portage.
>> 
>> I agree, it would indeed be nice to have a portage integration in
>> PackageKit, but given the rather unique way of handling packages in Gentoo,
>> I would consider PackageKit to be a rather poor choice for a package
>> manager.
>> USE flags, inability to resolve circular dependencies properly and of course
>> the advanced compile configuration that Gentoo offers are hard, if not
>> impossible to be handled by PackageKit. Which is why I think that, even if
>> there was a working integration of portage, it would not be used much. The
>> problem with Gentoo is that it more often than not requires the users to
>> make a choice instead of just settling for a package and clicking install.
>> 
>> --Patrick Lerner
>> 
> 

Re: [gentoo-soc] Graphical portage front-end

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 5917 bytes --]

On Sat, 2010-03-20 at 12:44 +0100, Auke Booij wrote:
> First things first, I would not know why someone should be using a
> graphical installer instead of xterm or one of its colleagues.
> 
> Anyway, the problems you are pointing out are exactly what you're
> sacrificing by using a GUI, and exactly the reason Gentoo doesn't have
> a graphical installer (or one that you should be using, anyway).

Different people think and use their system differently.  I do NOT
consider using/developing a graphical frontend for portage to be a
"sacrifice" to in usability.  There are things that a GUI is far better
at than a terminal, and vice/versa.  A well designed gui is great for
bringing large amounts of data together quickly and in a form that makes
it easy for a user to locate the relevant info required to make their
decision about a package to  upgrade/install, etc..

>  A lot
> of Portage's configuration consists of bash scripts, and any attempt
> to fully reproduce their capabilities in a GUI would lead to a big
> mess (point-and-click programming, *sigh*). If someone desperately
> wants a GUI, it would be for daily Portage activities, and definitely
> not for obscure feature x or y.

I think you misunderstood the purpose of the GUI here.  Kuroo was for
daily use, not just configuration changes.
> 
> Further, resolving dependencies is, in my opinion, outside the scope
> of a GUI. Functionality that isn't present in the command-line version
> of some program shouldn't be added just for the GUI version.
> 

The problem with dependency resolution has always been the lack of an
API in portage to get complete dependency graph, especially when
masked/keyworded packages were involved and the packages needed to
install.  Plus as I see it the needs of the GUI differ slightly from the
actual installing package manager.  In porthole we build and show a
complete dependency graph showing all dependencies for all use flag
conditionals, whether or not the installed conditions are met for the
dep, etc..

> That said, I'm sure some people would love a GUI integration of
> different package management tools (ie. search, install, sync...) into
> one big package, and it would definitely be a nice improvement to
> Sabayon.
> 
> tulcod.

There are 3 already for Gentoo.  This isn't Sabayon.

> 
> On Sat, Mar 20, 2010 at 12:25 PM, xqyz <xqyzii@gmail.com> wrote:
> > On 20 March 2010 11:16, Petteri Räty <betelgeuse@gentoo.org> wrote:
> >>
> >> Last year we had a project for PackageKit integration that was never
> >> integrated into the main tree. I would rather continue that work and
> >> then any PackageKit GUI could be used with Portage.
> >
> > I agree, it would indeed be nice to have a portage integration in
> > PackageKit, but given the rather unique way of handling packages in Gentoo,
> > I would consider PackageKit to be a rather poor choice for a package
> > manager.
> > USE flags, inability to resolve circular dependencies properly and of course
> > the advanced compile configuration that Gentoo offers are hard, if not
> > impossible to be handled by PackageKit. Which is why I think that, even if
> > there was a working integration of portage, it would not be used much. The
> > problem with Gentoo is that it more often than not requires the users to
> > make a choice instead of just settling for a package and clicking install.
> >
> > --Patrick Lerner
> >

I have installed gnome packagekit and the portage backend and tried it.
But (I am biased) I found the interface sucked big time.  I personally
thought that the packagekit work was nearly a waste of time.  From what
I can see, it was just a "Me Too" project to put the gentoo name in
front of a few more binary distro users, unlikely that it will ever be
used.  Possibly only by a few people migrating to gentoo who previously
used it until they discovered the native gentoo guis any of which are
better imho.  The only good thing from it is the backend code which
brings a proper API to portage one step closer to being a reality.  That
API has been on the TODO list and promised for many years.  The lack of
it has been one of the reasons the current guis have not had a better
connection to portage.  As for it not being pushed in the main tree, Zac
informed me that there were some problems with it that needs a proper
API in portage for it to be stable and reliable.  He also intends to
implement it ( as have others in previous years), but he is only one
person, already busy with the core development of portage.

If there is to be a project to with portage it should be the
implementation of a proper public API for apps to use such as porthole,
portato, himerge, etc..


> Hello,
> I would be interested in coding a new and improved graphical front-end
> for portage, similar to the old Kuroo Project. The reason why I want
> to start from scratch is that I'm not particular inclined to use QT as
> a toolkit, nor would I consider CPP my language of choice.
> Personally, I would prefer to go with a combination of Python and
> wxWidgets on this project. For one thing, performance should allow to
> switch to Python without too much speed-loss, and I also think using
> Python instead of CPP could attract more non-professional, casual
> coders to contribute to the project.
> 

Why do yet another gtk based portage frontend, there are 3 already.  The
idea was for a NATIVE QT implementation which is something htat KDE
users would like.  Besides that I find wxgtk lacking in many ways
compared to normal gtk interfaces.  If you want to work on a gtk
interface, I could always use more help with porthole, Necoro is
extremely busy with schooling and could use help with portato.  I
haven't talked with araujo enough to know if he needs help with himerge.

-- 
Brian Dolbec <brian.dolbec@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-soc] Graphical portage front-end

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 3047 bytes --]

On Sat, 2010-03-20 at 11:38 -0400, Eric Thibodeau wrote:
> In short, I agree with Tucold. Some sort of X-independant but aware
> (thinking curses here) front end to portage + glsa-checks + ability to
> select another install root (and throw in neworked eclean while at it)
> come to mind... I could see this as a useful front end to portage for,
> ie: managing multiple system images on say, the master node of a
> cluster ;) If one wants to be really neat feature to such an
> interface, the ability to install the same package onto multiple roots
> simultaneously.
> 
> ...my 2c.
> 
> Eric Thibodeau
> 

There have been attempts at an ncurses frontend before.  One was by a
porthole dev that was trying to implement a simplified version of it.
Unfortunately he did not get far into the project when work got it the
way and he needed to withdraw from all other projects.  The more recent
one I am aware of was by a former portage dev "genone".  From what I
gathered he was unable to find a decent ncurses toolkit to work with
that would not require a great deal of custom work to implement it.  I
have not heard anything more for some time now.

As for networked GUI ability.  Several years ago one of the porthole
devs came up with an experimental ability for porthole to connect to
remote hosts.  At the time there was too much else to do and work on,
not to mention the security concerns that would need to be properly
addressed.  I have always kept that that ability in my mind as something
to add in.  In recent times python3k brings with it the native ability
to import python modules from remote hosts using ssh.  That will make
secure remote connections possible and I think much easier to implement.
But that too would also be better to implement if portage had a proper
public API to use.  Adding the ability to push it to multiple systems
simultaneously should not be that much additional difficulty.  Again I
welcome some help in implementing that. 

As for other gentoolkit and portage apps, I have gotten involved in the
recent gentoolkit development in order to make the python based
utilities useable/importable directly into other python apps.  Namely to
create plugin's for porthole so it could gain access to the code used to
produce the info output and operations it performed with out resorting
to parsing terminal output, something which breaks often with version
upgrades, prone to parsing errors, limited flexibility.  A networked
eclean is now natively possible with only minor additional changes
(without running multiple instances, one for each host).  I am also
currently working on a plugin type system for emaint that should make it
easier to add/remove modules to as well as make it easier to implement
arch or other specific install needs  code changes without the need to
reconfigure or modify the interface or the command used to carry out the
task desired.  Hopefully the change will be accepted and implemented. 

-- 
Brian Dolbec <brian.dolbec@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-soc] Graphical portage front-end

[Patrick Lerner]

On Sat, 2010-03-20 at 09:02 -0700, Brian Dolbec wrote:
> [..] As for it not being pushed in the main tree, Zac
> informed me that there were some problems with it that needs a proper
> API in portage for it to be stable and reliable.  He also intends to
> implement it ( as have others in previous years), but he is only one
> person, already busy with the core development of portage.
> 
> If there is to be a project to with portage it should be the
> implementation of a proper public API for apps to use such as porthole,
> portato, himerge, etc..

Is there like any information out on how the communication between
client and portage would work? As in "Portage Daemon" or something along
the lines of python bindings?
In case I can help (with no previous experiences on creating public
APIs), I'd be glad to do so even outside the scope of SoC.

> If you want to work on a gtk
> interface, I could always use more help with porthole, Necoro is
> extremely busy with schooling and could use help with portato.  I
> haven't talked with araujo enough to know if he needs help with himerge.

I've looked into Porthole, which looks pretty similar to what I had in
mind when proposing a GTK portage front-end, so I'm going to look into
it a bit more.
Something I've actually wanted to do is having some kind of
background-process which would take care of syncing your tree and inform
you about outstanding updates similar to the update managers of Ubuntu
or Windows (systray icon + notify, like evolution does it with new
mail).
In Porthole all I found was the big upgrade button which immediatly
installed everything without even giving me a list of which updates are
there.
Nevertheless, kudos on the project, I'll look into contributing
something to it if I can, too.

--Patrick Lerner

Re: [gentoo-soc] Graphical portage front-end

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]

On Sun, 2010-03-21 at 23:14 +0100, Patrick Lerner wrote:
> On Sat, 2010-03-20 at 09:02 -0700, Brian Dolbec wrote:
> > [..] As for it not being pushed in the main tree, Zac
> > informed me that there were some problems with it that needs a proper
> > API in portage for it to be stable and reliable.  He also intends to
> > implement it ( as have others in previous years), but he is only one
> > person, already busy with the core development of portage.
> > 
> > If there is to be a project to with portage it should be the
> > implementation of a proper public API for apps to use such as porthole,
> > portato, himerge, etc..
> 
> Is there like any information out on how the communication between
> client and portage would work? As in "Portage Daemon" or something along
> the lines of python bindings?
> In case I can help (with no previous experiences on creating public
> APIs), I'd be glad to do so even outside the scope of SoC.

The portage public API is mostly coded in the form of the packagekit
portage backend which was one of last years soc projects.  The
packagekit bacend is in the gnome overlay if you want to look it over.
It is in 2 basic parts, 1 a "c" to python bridge to access the python
based portage interface code.  It is this interface code that is to be
integrated into portage proper as a public API. 

 I talked with zmedico about the portage public API and he said that it
does not need much modification to be a part of portage.  With some
recent code changes and split-ups, portage is now ready for more API
integration.  He will be doing it in the near future and plans it for a
2.1.9 release.

> 
> > If you want to work on a gtk
> > interface, I could always use more help with porthole, Necoro is
> > extremely busy with schooling and could use help with portato.  I
> > haven't talked with araujo enough to know if he needs help with himerge.
> 
> I've looked into Porthole, which looks pretty similar to what I had in
> mind when proposing a GTK portage front-end, so I'm going to look into
> it a bit more.
> Something I've actually wanted to do is having some kind of
> background-process which would take care of syncing your tree and inform
> you about outstanding updates similar to the update managers of Ubuntu
> or Windows (systray icon + notify, like evolution does it with new
> mail).

I've wanted to do this for some time now too :)

Also I am starting a complete rewrite of porthole's backend structure
that will be able to make proper use of that new API, not to mention be
easier to create a pkgcore backend as well.  Help is welcomed and
appreciated.  Other things on my TODO list are full layman support,
individual overlay tree listings, full binpkg support, possibly even
multiple repo source support, py3k readiness, as pygtk is planned to add
python-3 support this spring...

> In Porthole all I found was the big upgrade button which immediatly
> installed everything without even giving me a list of which updates are
> there.

Ah, when it presented you with the small dialog box asking if you wanted
all pkgs in your world file updated you clicked "Yes".  Had you clicked
"NO" or selected the "Upgradable Packages" view ( that box next to
"View:" on the left, right above the category listings.  It would have
shown you "ALL" the pkgs that have an upgrade available.  From that view
the "Upgrade" button only upgrades the pkgs that have been selected.

Use the Help ==> Contents menu options to open your browser to the html
help files installed with porthole. They give you a good overview of how
it works and it's capabilities. ;)


> Nevertheless, kudos on the project, I'll look into contributing
> something to it if I can, too.
> 
> --Patrick Lerner
> 
> 

I look forward to hearing from you.  IRC channels are #gentoo-guis,
#porthole

-- 
Brian Dolbec <brian.dolbec@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]