/*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.
Portage consists of one command 'emerge' with _many_ arguments to> put it
in. For the n00b, remembering and executing all of the correct arguments
can be a bit difficult. A GUI program called Kportage had been created a
while back. It was written in QT and had many bugs. The idea of Kportage
is great but the actual implementation was not. New ideas have been formed
in an attempt to provide users with the ease and power> of controlling
portage through a GUI.
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++. 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.
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.
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.
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.
firstname.lastname@example.org mailing list