1 |
munky@××××××.com said: |
2 |
|
3 |
> /*Idea for new project known as PortageUI to be a front end to Portage*/ |
4 |
> |
5 |
> Portage or commonly known as 'emerge' is the powerful package system of |
6 |
> Gentoo. Gentoo's success is directly related to the quality of Portage. |
7 |
> Portage has the ability to find sources, compile, and install the |
8 |
> binaries. It can also update all programs and keep your system up to date. |
9 |
> Portage consists of one command 'emerge' with _many_ arguments to> put it |
10 |
> in. For the n00b, remembering and executing all of the correct arguments |
11 |
> can be a bit difficult. A GUI program called Kportage had been created a |
12 |
> while back. It was written in QT and had many bugs. The idea of Kportage |
13 |
> is great but the actual implementation was not. New ideas have been formed |
14 |
> in an attempt to provide users with the ease and power> of controlling |
15 |
> portage through a GUI. |
16 |
|
17 |
It's a great idea, and needed project. I think you should also contect the |
18 |
portage manager, to explain how you'll interact with portage, and if he has |
19 |
tricks to do things better. I also think that you hsould take a look at some |
20 |
portage API projects that have emerged (!), namely gentoolkit frontends. |
21 |
|
22 |
> |
23 |
> PortageUI is an idea at this point and will remain such for some time.Some |
24 |
> basic decisions have been decided as for the languages of> PortageUI. The |
25 |
> head devs (Munky, Frog) are big fans of C, not its offspring C++. Kportage |
26 |
> had been written in C++ and we feel that it is not the best language for |
27 |
> the job. We initially planed on using ansi C for this project, but Python |
28 |
> has also been suggested. Both the devs of this project are quite weak in |
29 |
> Python, which may influence our decision. We also plan to use GTK2. |
30 |
> Suggestions concerning language and toolkit choice are most welcome. |
31 |
|
32 |
my opinion: C, C++, java programs are long to develop, and difficult to |
33 |
maintain. Scripting language are easy to maintain, easier to be retaken by |
34 |
other devs, and faster to develop. So I prefer perl, python, ruby, over C C++ |
35 |
java. Now, python is easier to learn than perl, despite the fact that it seems |
36 |
less powerfulle, and that it's slower. But we don't care for a frontend |
37 |
application. Ruby is nice, but even slower than python, and have less libraries |
38 |
available. So the good choici would be imho python. Now for the gui, you can |
39 |
use gtk2, it's a good choice for me, but qt is also perfect for the job. |
40 |
|
41 |
> |
42 |
> Kportage really only provided a GUI for portage not adding on any new |
43 |
> ideas. There are many things that users do with portage, or can do with |
44 |
> portage that they do. For instance, the easiest way to keep your system up |
45 |
> to date is "emerge -u world". This will update all applications that have |
46 |
> been installed using portage, including your kernel libraries. This is |
47 |
> very important for those users whom don't update single applications. |
48 |
> Thus, it seems optimal to integrate PortageUI with cron and have various |
49 |
> tasks set. Such as a weekly "emerge sync" and a monthly "emerge -u world". |
50 |
> This would help to keep your system up to date and secure. |
51 |
|
52 |
That's a good idea. |
53 |
|
54 |
> |
55 |
> In reference to the application of the GUI itself, considering the> |
56 |
> _great_ size of the portage tree, it seems fit to use a database to keep> |
57 |
> track of the data. The best database to use would probably be that of |
58 |
> Postgresql. The database can hold a list of each ebuild and various data |
59 |
> for it. This data will include: installed version, current version, |
60 |
> dependencies, as well as its README, and other docs. In addition, the db |
61 |
> will hold specific categorizes that the ebuild fits in. The ebuilds are |
62 |
> already sorted in a directory structure, but in reality that is not as |
63 |
> user friendly or easy to understand as simple categories. The user will |
64 |
> have the ability to modify the categories to their own interpretation. |
65 |
|
66 |
I'm strongly against asking the user to install (and configure) a postgresql db |
67 |
on his system. You should look at sqlite, a sql relational database which is |
68 |
light fast, and fits in one single file, so no installation, no configuration |
69 |
required. The drawbacks are that it'ssingle user, and less optimized for very |
70 |
large database. But this application will be single user, and the database |
71 |
won't be big, so sqlite is the perfect candidate imo. |
72 |
|
73 |
-- |
74 |
dams |
75 |
|
76 |
-- |
77 |
gentoo-desktop-research@g.o mailing list |