[gentoo-desktop-research] Proposal for Portage Program

[gentoo-desktop-research] Proposal for Portage Program

[munky]

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

--
-Dovid Kopel
-=mUnky=-

---
http://www.usalug.org

--
gentoo-desktop-research@gentoo.org mailing list

[gentoo-desktop-research] Proposal for Portage Program

[munky]

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

--
-Dovid Kopel
-=mUnky=-

---
http://www.usalug.org

--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] Proposal for Portage Program

[foser]

On Thu, 2003-11-20 at 03:16, munky@munkys.com 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@gentoo.org mailing list

Re: [gentoo-desktop-research] Proposal for Portage Program

[dams]

foser <foser@gentoo.org> said:


[...]

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

I agree very much (is that english?) with you on that. I think we forgot this
part of research : which standard to follow for each desktop situations. I note
this for further researchs

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list