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-desktop-research
Navigation:
Lists: gentoo-desktop-research: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-desktop-research@g.o
From: foser <foser@g.o>
Subject: Re: Proposal for Portage Program
Date: Fri, 21 Nov 2003 00:08:13 +0100
On Thu, 2003-11-20 at 03:16, munky@... wrote:
> /*Idea for new project known as PortageUI to be a front end to Portage*/
> 
> Portage or commonly known as 'emerge' is the powerful package system of
> Gentoo. Gentoo's success is directly related to the quality of Portage.
> Portage has the ability to find sources, compile, and install the
> binaries. It can also update all programs and keep your system up to date.

You are not kidding me right, does such a distro exist ? ;)

> PortageUI is an idea at this point and will remain such for some time.Some
> basic decisions have been decided as for the languages of> PortageUI. The
> head devs (Munky, Frog) are big fans of C, not its offspring C++.

Head devs for this project i assume or did i miss something ? And are
there any reasons beyond a general disliking of C++ for choosing C,
disregarding the fact that there are dozens of other capable languages
out there.

>  Kportage
> had been written in C++ and we feel that it is not the best language for
> the job. We initially planed on using ansi C for this project, but Python
> has also been suggested. Both the devs of this project are quite weak in
> Python, which may influence our decision. We also plan to use GTK2.
> Suggestions concerning language and toolkit choice are most welcome.

I can't be against GTK+ 2 of course, but more important to me than the
toolkit is the UI design. I would suggest it should follow the GNOME HIG
for consistency for a start.

> Kportage really only provided a GUI for portage not adding on any new
> ideas. There are many things that users do with portage, or can do with
> portage that they do. For instance, the easiest way to keep your system up
> to date is "emerge -u world". This will update all applications that have
> been installed using portage, including your kernel libraries. This is
> very important for those users whom don't update single applications.
> Thus, it seems optimal to integrate PortageUI with cron and have various
> tasks set. Such as a weekly "emerge sync" and a monthly "emerge -u world".
> This would help to keep your system up to date and secure.

I wouldn't suggest cronning things like sys wide updates as dev, nor
should we be promoting it by putting it in an 'official' (?) UI. Anyway
i see no reason to have that integrated in a UI, people who want to cron
updates (which i consider a bad practice), should be able to do that
themselves (see it as a skill qualifier).

> In reference to the application of the GUI itself, considering the>
> _great_ size of the portage tree, it seems fit to use a database to keep>
> track of the data. The best database to use would probably be that of
> Postgresql. The database can hold a list of each ebuild and various data
> for it. This data will include: installed version, current version,
> dependencies, as well as its README, and other docs. In addition, the db
> will hold specific categorizes that the ebuild fits in. The ebuilds are
> already sorted in a directory structure, but in reality that is not as
> user friendly or easy to understand as simple categories. The user will
> have the ability to modify the categories to their own interpretation.

Do you really know what you are getting into ? I wrote a gtk gui before
i became a dev, it worked okayish, but i had to do all portage
type-o-logic myself and that was at a time where portage and its related
files (caches/db/etc.) were much simpler. Actually, rewriting that tool
has been stuck on the fact that portage has virtually no usable API.
That is what lacks and that is what needs fixing before any useful UI
tools can be made (in my opinion).

Using a db is all nice, but it would be duplication of information (and
staying in sync might become very troublesome). Again, portage lacks
here : i should have a unified db and an API to access it from outside.

> At this point in time, both devs are going to be working on basic
> prototypes as to how we will accomplish our goal. We are brushing up on
> our knowledge of GTK2 and going over Python. We won't begin coding until
> all the planning is done before-hand. If everything goes accordingly, it
> seems realistic to say coding will begin around a month or so after the
> project is approved.

> Please let us know what you think of this proposal. It is just a series of
> ideas, and much of it can be changed; nothing is set in stone.

As much as i like the idea of a proper GUI for portage, I'm uncertain if
you know what you are getting into.

I suggest at least a total backend - frontend separation, because i
think the backend is gonna be messy.

- foser


--
gentoo-desktop-research@g.o mailing list

Replies:
Re: Proposal for Portage Program
-- dams
References:
Proposal for Portage Program
-- munky
Navigation:
Lists: gentoo-desktop-research: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Proposal for Portage Program
Next by thread:
Re: Proposal for Portage Program
Previous by date:
Re: Final thoughts on PortageUI
Next by date:
Re: Gentoo-desktop howto fix-up


Updated Jun 17, 2009

Summary: Archive of the gentoo-desktop-research mailing list.

Donate to support our development efforts.

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