From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FJCJk-0002ZN-9s for garchives@archives.gentoo.org; Tue, 14 Mar 2006 16:24:16 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5.20060308/8.13.5) with SMTP id k2EGNWIF011741; Tue, 14 Mar 2006 16:23:32 GMT Received: from priv-edtnes51.telusplanet.net (outbound04.telus.net [199.185.220.223]) by robin.gentoo.org (8.13.5.20060308/8.13.5) with ESMTP id k2EGNUfT006675 for ; Tue, 14 Mar 2006 16:23:31 GMT Received: from big_squirt.dol-sen.ca ([154.20.205.249]) by priv-edtnes51.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060314162330.FDUW18753.priv-edtnes51.telusplanet.net@big_squirt.dol-sen.ca> for ; Tue, 14 Mar 2006 09:23:30 -0700 Subject: Re: [gentoo-portage-dev] Few things, which imho would make portage better From: Brian To: gentoo-portage-dev@lists.gentoo.org In-Reply-To: References: <4416A4C1.6090903@gentoo.org> <1142348654.10776.38.camel@localhost> Content-Type: text/plain Date: Tue, 14 Mar 2006 08:21:45 -0800 Message-Id: <1142353305.10776.65.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 5ac0f574-965f-4832-9d81-f141a7617e15 X-Archives-Hash: a81d156169e7979dacaa6b535b8c053a On Tue, 2006-14-03 at 17:32 +0200, tvali wrote: > 2006/3/14, Brian : > > On Tue, 2006-14-03 at 16:33 +0200, tvali wrote: > > If I recall, (there has been lots of discussion about converting portage > > to use databases, just check the mail archives and forum) portage > > already has sqlite support, but is not yet used. Sqlite is smaller and > > has less dependencies than mysql. > > How to use sqlite support in portage? > > > Also, many of the features you talked about are already implemented in > > porthole, such as continuing after a failed package, filtering out > > warnings, important messages, etc.. > > > > Check it out. > > Is this ok: > !!! All ebuilds that could satisfy "porthole" have been masked. > Or is there any, which is not masked? It is masked because of a gtk bug that will segfault if you expand the "Dependencies" listing in the upgradeable view. It will segfault when you return to any other view unless you make it re-sort the list or make it rebuild the list. It is something that did not occur in earlier versions of gtk. Actually earlier versions of porthole were much more unstable and segfaulted due to numerous other coding errors that were difficult to track down, but were not masked. Currently the only fix is to re-code porthole to use the treeviews differently (a fairly major undertaking I do not have time for yet). Currently each view has it's own model and we switch the models for the treeview. The other way would be to have only one model and clear the model and re-populate it with different data when switching views. That is probably the better way to do it in the long run, especially if someone was to make a KDE interface for it. That way it would be much easier to use either a GTK or KDE interface. > > And -- if portage is meant as main engine and porthole as it's gui, > isnt it a bit fuzzy to add speed-ups to porthole instead of portage? > If it continues like that, it may end up with someone writing > command-line tool for controlling porthole :P I think that if > application has 2 layers, one for logic and another for GUI, then it's > maybe not the best way of coding to add such kind of features to GUI > part of package. I personally would definitely try to make portage > itself support indexing and other such stuff to keep things clean. Am > i wrong? Or is it in plans to make gentoo a GUI linux with very weak > command-line support? > > I think that GUI code would be *clean* if it's just a GUI! > If you can get it implemented in portage so much the better. If not, I have had feature requests to add it to porthole to speed up description searching. (many users use porthole and command line tools) It can be slow currently in porthole which does not get descriptions for searches unless enabled, then it fetches all descriptions. After that once loaded searches are quick again. Adding support for the esearch db would speed that up since a db is already created and hopefully already updated. -- Brian -- gentoo-portage-dev@gentoo.org mailing list