On Tue, 2006-14-03 at 17:32 +0200, tvali wrote:
> 2006/3/14, Brian <[EMAIL PROTECTED]>:
> > 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


gentoo-portage-dev@gentoo.org mailing list

Reply via email to