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
On Thu, 2003-11-20 at 03:16, munky@××××××.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@g.o mailing list