Gentoo Archives: gentoo-portage-dev

From: Brian <dol-sen@×××××.net>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Few things, which imho would make portage better
Date: Tue, 14 Mar 2006 16:24:16
Message-Id: 1142353305.10776.65.camel@localhost
In Reply to: Re: [gentoo-portage-dev] Few things, which imho would make portage better by tvali
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