1 |
On K, 2010-06-23 at 09:33 +0530, Arun Raghavan wrote: |
2 |
> On 23 June 2010 01:47, Mike Auty <ikelos@g.o> wrote: |
3 |
> [...] |
4 |
> >> Which should not be an issue since any library that has some sort of |
5 |
> >> introspection can use this flag (and the use.desc can be changed |
6 |
> >> appropriately at that time if it does not use gobject-introspection). |
7 |
> > |
8 |
> > Why have to change it in the future (and probably split it into two |
9 |
> > flags then), when the choice hasn't been made yet? Or, to put your own |
10 |
> > question to you, why are you vehemently for "introspection" when others |
11 |
> > have shown concern with the choice? As far as I can see, the only |
12 |
> > difference is requiring a slightly longer use_enable line. |
13 |
> |
14 |
> Mostly because I don't want to coin a new term if it's not absolutely necessary. |
15 |
> |
16 |
> That said, you're right - more people seem to be comfortable with |
17 |
> "gintrospection" than plain "introspection". If no further objections |
18 |
> arise, we'll go with "gintrospection". |
19 |
|
20 |
I object. |
21 |
|
22 |
|
23 |
gintrospection doesn't describe anything. It's very hard to understand |
24 |
from the USE flag name that it deals with introspection, as opposed, to, |
25 |
uh, gint's or who knows what. |
26 |
|
27 |
USE flags starting with "g" usually denote support for some GNU package, |
28 |
not gnome, per some actual looking at use.desc. |
29 |
|
30 |
Nothing stops QtCore packages to use the same USE flag name for the same |
31 |
purpose - introspection. USE flags are primarily supposed to enable |
32 |
certain functionality, not "allow to depend on this package". That |
33 |
functionality is introspection. It just happens that the only framework |
34 |
this is currently supported in is on top of GObject and the appropriate |
35 |
gobject-introspection package. |
36 |
Introspection has nothing to do with GNOME. Most GNOME modules are |
37 |
written in C and don't need introspection information (primary exception |
38 |
being gnome-shell and its javascript stuff). All packages that currently |
39 |
depend on PyGTK will and should eventually use PyGi and in turn the |
40 |
introspection information provided by the necessary used libraries. This |
41 |
includes many GUI software that has no relation to GNOME, other than |
42 |
using the same toolkit. |
43 |
|
44 |
I can't imagine what else introspection means than what this USE flag is |
45 |
proposed to provide to many libraries (would api-introspection be more |
46 |
clear?), all of which just happen to be GObject based right now (and as |
47 |
such detailed in the currently proposed global USE flag description), as |
48 |
other base frameworks currently don't have any introspection support to |
49 |
our knowledge. |
50 |
|
51 |
Note that you will soon not be able to really avoid |
52 |
gobject-introspection package on desktop systems (unless you are a Qt |
53 |
junky that refuses to install anything not based on Qt), so this USE |
54 |
flag really isn't about dependency control at all. It's about defining |
55 |
if embedded images need a .typelib introspection file at runtime or not. |
56 |
So that embedded GUI image builders would be able to globally disable |
57 |
the USE flag and enable it per-package as necessary by applications |
58 |
(represented with USE depends). If it weren't for that, we'd simply |
59 |
always install them, they are just not that big compared to the include |
60 |
files that get always installed too. But embedded guys can easily delete |
61 |
all of /usr/include, but typelibs (containing the introspection data) |
62 |
may be necessary at runtime. |
63 |
|
64 |
|
65 |
-- |
66 |
Mart Raudsepp |
67 |
Gentoo Developer |
68 |
Mail: leio@g.o |
69 |
Weblog: http://blogs.gentoo.org/leio |