1 |
* Paul de Vrieze <pauldv@g.o> schrieb: |
2 |
|
3 |
<snip> |
4 |
|
5 |
> > I just want to keep things simple. We're talking about introducing |
6 |
> > new (additional) logic. This has to be maintained. And it doesn't |
7 |
> > actually *solve* the problem which is this discussion was started. |
8 |
> |
9 |
> Removing the stuff from the ebuild and maintaining two ebuilds that |
10 |
> must be synchronized with eachother is complex. |
11 |
|
12 |
Where exactly have the two packages gtk1 and gtk2 to be synchonized ? |
13 |
|
14 |
<snip> |
15 |
|
16 |
> > Rember: we started with the thesis, "grandma wants graphical |
17 |
> > frontends whereever possible". This is in fact not an technical |
18 |
> > issue, instead a matter of personal taste, or lets say, an individual |
19 |
> > system configuration. Grandma wants to click, okay, so she should |
20 |
> > use graphical applications. She's not interested what sits behind, |
21 |
> > she just wants to have a buch of applications. And she also doesn't |
22 |
> > wann have anything to do with emerge and useflags. She just wants |
23 |
> > to have a choice between a bunch of end-user applications. |
24 |
> > That's the job of an Grandma-(sub-)distro. |
25 |
> |
26 |
> gentoo is not a grandma distro and does not try to be so. |
27 |
|
28 |
No, it is not, and it shall not. |
29 |
But this was example at the start of this whole discussion. |
30 |
|
31 |
I understand the intentions to make such things easier, |
32 |
but I really doubt it will be an *real* solution. |
33 |
|
34 |
If you see it as a huge set of possible system configurations |
35 |
(defined by list of installed packages, versions, useflags, ...), |
36 |
each individual configuration as an element of this set, then our |
37 |
Grandma-scenario is an subset: we cut out a bunch of elements |
38 |
which may be interesting for the intended audience. |
39 |
|
40 |
So in other words: we need some kind of preselection. |
41 |
Default useflags and useflag aliases on profile basis. |
42 |
|
43 |
Maybe there could be an extra file, ie. package.use.alias |
44 |
|
45 |
foo/bar gui=gtk |
46 |
blah/blubb gui=qt2 |
47 |
... |
48 |
|
49 |
I'm not sure if this alias handling should be done by emerge, |
50 |
or better by some frontend (I learned that explicit downgrade |
51 |
warnings should be done by an frontend, so why should useflag |
52 |
aliasing shouldn't ?). But I'm sure these information should |
53 |
not go directly to the ebuilds. |
54 |
|
55 |
<snip> |
56 |
|
57 |
> > Okay, let's say we want to intruduce an meta-useflag for "GUI" |
58 |
> > (although having additional GUIs in the same package as the |
59 |
> > backend isn't what I consider clean design). If there's just *one* |
60 |
> > than it's easy - just an alias. But what's if we have more ? |
61 |
> > Who makes the decision, which one to take ? Based on what rules ? |
62 |
> |
63 |
> The council makes the decisions. |
64 |
|
65 |
How detailed is this decision ? |
66 |
Global for all or by package ? |
67 |
|
68 |
<snip> |
69 |
|
70 |
> > Yes. For optional features. Additional programs aren't features of |
71 |
> > some other program, but additional programs. |
72 |
> |
73 |
> You should read up on your history. Useflags are as well for additional |
74 |
> programs as for features. This is especially true when things should |
75 |
> be kept together as they are tightly coupled. |
76 |
|
77 |
This soon gets confusing for many people. See the dhcp thread. |
78 |
There're lots of discussions about the server and client useflags. |
79 |
Could have been done easily by splitting off into two packages, |
80 |
one for server, one for client and providing an meta package for |
81 |
people who like to have both. |
82 |
|
83 |
<snip> |
84 |
|
85 |
> > I consider it *very* clean. What could be easier than have an |
86 |
> > consistent database which *knows* what's installed on the system |
87 |
> > instead of having to run lots of esoteric tests which shall *guess* |
88 |
> > it somehow ?! |
89 |
> |
90 |
> The tests don't actually guess. |
91 |
|
92 |
Really ? |
93 |
|
94 |
In the recent years I had do lots of fixes in many autoconf stuff |
95 |
(autotools itself as well as configure.ac's) to get them working |
96 |
on situations where building and target systems aren't the same. |
97 |
Obviously this is not the case for gentoo (it's an self-building |
98 |
distro, not system A building for an completely different system B), |
99 |
so you probably don't get involved in such problems. |
100 |
|
101 |
For example, if you're building in an sysroot'ed environment, you |
102 |
have tweak patches - "/" mostly doesn't mean the running systems's |
103 |
root, but the target system image. |
104 |
|
105 |
Many packages provide their own autoconf macros for detecting if |
106 |
the package is installed. In 99% they don't provide more information |
107 |
than can be found in an .pc file. But they introduce additional |
108 |
complexity, could have been nailed down by an simple pkg-config |
109 |
query. You don't even need autoconf for that - can also directly |
110 |
be done within an makefile. But if each package provides its own |
111 |
implementation, they all have to be tweaked by their own for such |
112 |
non-stardard situations. When using pkg-config, there's only |
113 |
one central point to intercept. |
114 |
|
115 |
If you regenerate the configure stuff of some package A which *may* |
116 |
require some package B (if the appropriate feature is selected), |
117 |
you will need to have the package B installed, so the macros can |
118 |
be found. Not because it will be actually required, but just for |
119 |
getting the configure script built. Okay, some packages ship a |
120 |
copy of the macros by their own, but this again is additional |
121 |
complexity: the package developers have to keep it up-to-date. |
122 |
|
123 |
<snip> |
124 |
|
125 |
> The main problem though is that pkg-config encourages wrong linking. |
126 |
|
127 |
No, it doesn't encourage it. Maybe it takes some presure to do so. |
128 |
But the individual autoconf macros do the same. |
129 |
|
130 |
BTW: there are scenarios, where such dependency information within |
131 |
the shared objects are not feasible. For example, if you don't |
132 |
*want* to have strict dependency graphs, instead several shared |
133 |
objects making up an (virtual) library. Most of these cases could |
134 |
be circumvented by very clean and strict design from gound up. |
135 |
C is not Oberon. C allows such non-strict linking, like it or not. |
136 |
|
137 |
If you really want to *encourage* this strictness, there are far |
138 |
better concepts, you could go in an direction like |
139 |
|
140 |
http://wiki.metux.de/public/TreeBuild |
141 |
|
142 |
and get rid off much, much complexits immediately. |
143 |
|
144 |
But I had to learn, it's not the question what *could* be done, |
145 |
instead what's *actually* done. People don't seem to like those |
146 |
approaches very much. I tried to port many packages to treebuild, |
147 |
but just me alone isn't far enough manpower for that. |
148 |
So I tried to get some steps back and repair packages to at least |
149 |
go away from individual macros. |
150 |
|
151 |
|
152 |
BTW: you didn't answer how you wanna get the dependencies solved |
153 |
with static archives or on platforms which don't provide these |
154 |
dependency information. Maybe I'm not up-to-date, but I didn't |
155 |
ever see dll dependencies on win32. |
156 |
|
157 |
> > If necessary, this database query can be intercepted easily. With |
158 |
> > the esoteric testing its very complicated or at least work intensive. |
159 |
> |
160 |
> There is nothing esoteric about checking for the existence of libfoo. |
161 |
|
162 |
You miss the question of installation pathes. Any you miss the |
163 |
dozens of --with-libfoo=... options. |
164 |
|
165 |
Obviously there's a strong interest that certain libraries can be |
166 |
installed in specific locations (ie. for MVCC, etc) and client |
167 |
packages need to find them. |
168 |
|
169 |
BTW: an pkg-config query is much, much faster than building a whole |
170 |
hello-world just for checking if some package is there. |
171 |
|
172 |
And another scenario for pkg-config: packages are not necessarily |
173 |
equal with (shared) libraries. For example the -proto packages |
174 |
of Xorg. How do you intend to handle that ? |
175 |
|
176 |
<snip> |
177 |
|
178 |
> > Well, how would you get certain search pathes (-I, -L, ...) |
179 |
> > additional includes, dependency info for evrything but elf-so, ie .a ? |
180 |
> |
181 |
> The thing is you don't should not link the dependent libs of a dependency. |
182 |
> That way you don't need to recompile if (say gtk was compiled with a new |
183 |
> libpng version) |
184 |
|
185 |
Yes, of course. Such double-dependencies are bad. But it's not an |
186 |
pkg-config issue. If people write bad .pc files, you really can't |
187 |
blame pkg-config for that. It has proper dependency handling. |
188 |
|
189 |
Again, you missed to answer my question: how to you intend to |
190 |
handle non-default search pathes ? |
191 |
|
192 |
|
193 |
cu |
194 |
-- |
195 |
--------------------------------------------------------------------- |
196 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
197 |
--------------------------------------------------------------------- |
198 |
Please visit the OpenSource QM Taskforce: |
199 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
200 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
201 |
http://patches.metux.de/ |
202 |
--------------------------------------------------------------------- |
203 |
-- |
204 |
gentoo-dev@g.o mailing list |