1 |
On Tue, 2006-14-03 at 17:32 +0200, tvali wrote: |
2 |
> 2006/3/14, Brian <dol-sen@×××××.net>: |
3 |
> > On Tue, 2006-14-03 at 16:33 +0200, tvali wrote: |
4 |
> > If I recall, (there has been lots of discussion about converting portage |
5 |
> > to use databases, just check the mail archives and forum) portage |
6 |
> > already has sqlite support, but is not yet used. Sqlite is smaller and |
7 |
> > has less dependencies than mysql. |
8 |
> |
9 |
> How to use sqlite support in portage? |
10 |
> |
11 |
> > Also, many of the features you talked about are already implemented in |
12 |
> > porthole, such as continuing after a failed package, filtering out |
13 |
> > warnings, important messages, etc.. |
14 |
> > |
15 |
> > Check it out. |
16 |
> |
17 |
> Is this ok: |
18 |
> !!! All ebuilds that could satisfy "porthole" have been masked. |
19 |
> Or is there any, which is not masked? |
20 |
|
21 |
It is masked because of a gtk bug that will segfault if you expand the |
22 |
"Dependencies" listing in the upgradeable view. It will segfault when |
23 |
you return to any other view unless you make it re-sort the list or make |
24 |
it rebuild the list. It is something that did not occur in earlier |
25 |
versions of gtk. Actually earlier versions of porthole were much more |
26 |
unstable and segfaulted due to numerous other coding errors that were |
27 |
difficult to track down, but were not masked. |
28 |
|
29 |
Currently the only fix is to re-code porthole to use the treeviews |
30 |
differently (a fairly major undertaking I do not have time for yet). |
31 |
Currently each view has it's own model and we switch the models for the |
32 |
treeview. The other way would be to have only one model and clear the |
33 |
model and re-populate it with different data when switching views. That |
34 |
is probably the better way to do it in the long run, especially if |
35 |
someone was to make a KDE interface for it. That way it would be much |
36 |
easier to use either a GTK or KDE interface. |
37 |
|
38 |
> |
39 |
> And -- if portage is meant as main engine and porthole as it's gui, |
40 |
> isnt it a bit fuzzy to add speed-ups to porthole instead of portage? |
41 |
> If it continues like that, it may end up with someone writing |
42 |
> command-line tool for controlling porthole :P I think that if |
43 |
> application has 2 layers, one for logic and another for GUI, then it's |
44 |
> maybe not the best way of coding to add such kind of features to GUI |
45 |
> part of package. I personally would definitely try to make portage |
46 |
> itself support indexing and other such stuff to keep things clean. Am |
47 |
> i wrong? Or is it in plans to make gentoo a GUI linux with very weak |
48 |
> command-line support? |
49 |
> |
50 |
> I think that GUI code would be *clean* if it's just a GUI! |
51 |
> |
52 |
|
53 |
If you can get it implemented in portage so much the better. If not, I |
54 |
have had feature requests to add it to porthole to speed up description |
55 |
searching. (many users use porthole and command line tools) It can be |
56 |
slow currently in porthole which does not get descriptions for searches |
57 |
unless enabled, then it fetches all descriptions. After that once |
58 |
loaded searches are quick again. Adding support for the esearch db |
59 |
would speed that up since a db is already created and hopefully already |
60 |
updated. |
61 |
|
62 |
-- |
63 |
Brian <dol-sen@×××××.net> |
64 |
|
65 |
-- |
66 |
gentoo-portage-dev@g.o mailing list |