Gentoo Archives: gentoo-desktop-research

From: foser <foser@g.o>
To: gentoo-desktop-research@g.o
Subject: Re: [gentoo-desktop-research] Proposal for Portage Program
Date: Thu, 20 Nov 2003 23:08:25
Message-Id: 1069369693.4881.30.camel@rivendell
In Reply to: [gentoo-desktop-research] Proposal for Portage Program by munky@munkys.com
1 On Thu, 2003-11-20 at 03:16, munky@××××××.com wrote:
2 > /*Idea for new project known as PortageUI to be a front end to Portage*/
3 >
4 > Portage or commonly known as 'emerge' is the powerful package system of
5 > Gentoo. Gentoo's success is directly related to the quality of Portage.
6 > Portage has the ability to find sources, compile, and install the
7 > binaries. It can also update all programs and keep your system up to date.
8
9 You are not kidding me right, does such a distro exist ? ;)
10
11 > PortageUI is an idea at this point and will remain such for some time.Some
12 > basic decisions have been decided as for the languages of> PortageUI. The
13 > head devs (Munky, Frog) are big fans of C, not its offspring C++.
14
15 Head devs for this project i assume or did i miss something ? And are
16 there any reasons beyond a general disliking of C++ for choosing C,
17 disregarding the fact that there are dozens of other capable languages
18 out there.
19
20 > Kportage
21 > had been written in C++ and we feel that it is not the best language for
22 > the job. We initially planed on using ansi C for this project, but Python
23 > has also been suggested. Both the devs of this project are quite weak in
24 > Python, which may influence our decision. We also plan to use GTK2.
25 > Suggestions concerning language and toolkit choice are most welcome.
26
27 I can't be against GTK+ 2 of course, but more important to me than the
28 toolkit is the UI design. I would suggest it should follow the GNOME HIG
29 for consistency for a start.
30
31 > Kportage really only provided a GUI for portage not adding on any new
32 > ideas. There are many things that users do with portage, or can do with
33 > portage that they do. For instance, the easiest way to keep your system up
34 > to date is "emerge -u world". This will update all applications that have
35 > been installed using portage, including your kernel libraries. This is
36 > very important for those users whom don't update single applications.
37 > Thus, it seems optimal to integrate PortageUI with cron and have various
38 > tasks set. Such as a weekly "emerge sync" and a monthly "emerge -u world".
39 > This would help to keep your system up to date and secure.
40
41 I wouldn't suggest cronning things like sys wide updates as dev, nor
42 should we be promoting it by putting it in an 'official' (?) UI. Anyway
43 i see no reason to have that integrated in a UI, people who want to cron
44 updates (which i consider a bad practice), should be able to do that
45 themselves (see it as a skill qualifier).
46
47 > In reference to the application of the GUI itself, considering the>
48 > _great_ size of the portage tree, it seems fit to use a database to keep>
49 > track of the data. The best database to use would probably be that of
50 > Postgresql. The database can hold a list of each ebuild and various data
51 > for it. This data will include: installed version, current version,
52 > dependencies, as well as its README, and other docs. In addition, the db
53 > will hold specific categorizes that the ebuild fits in. The ebuilds are
54 > already sorted in a directory structure, but in reality that is not as
55 > user friendly or easy to understand as simple categories. The user will
56 > have the ability to modify the categories to their own interpretation.
57
58 Do you really know what you are getting into ? I wrote a gtk gui before
59 i became a dev, it worked okayish, but i had to do all portage
60 type-o-logic myself and that was at a time where portage and its related
61 files (caches/db/etc.) were much simpler. Actually, rewriting that tool
62 has been stuck on the fact that portage has virtually no usable API.
63 That is what lacks and that is what needs fixing before any useful UI
64 tools can be made (in my opinion).
65
66 Using a db is all nice, but it would be duplication of information (and
67 staying in sync might become very troublesome). Again, portage lacks
68 here : i should have a unified db and an API to access it from outside.
69
70 > At this point in time, both devs are going to be working on basic
71 > prototypes as to how we will accomplish our goal. We are brushing up on
72 > our knowledge of GTK2 and going over Python. We won't begin coding until
73 > all the planning is done before-hand. If everything goes accordingly, it
74 > seems realistic to say coding will begin around a month or so after the
75 > project is approved.
76
77 > Please let us know what you think of this proposal. It is just a series of
78 > ideas, and much of it can be changed; nothing is set in stone.
79
80 As much as i like the idea of a proper GUI for portage, I'm uncertain if
81 you know what you are getting into.
82
83 I suggest at least a total backend - frontend separation, because i
84 think the backend is gonna be messy.
85
86 - foser
87
88
89 --
90 gentoo-desktop-research@g.o mailing list

Replies