1 |
* Paul de Vrieze <pauldv@g.o> schrieb: |
2 |
|
3 |
<snip> |
4 |
|
5 |
> > Well, I don't consider reducing complexity "frivolous" ;-o |
6 |
> |
7 |
> Which reduction for which complexity? Do you want to bring everyone's |
8 |
> systems to a grinding halt, just because you can't understand the |
9 |
> "complexity" of useflags. |
10 |
|
11 |
I just want to keep things simple. We're talking about introducing |
12 |
new (additional) logic. This has to be maintained. And it doesn't |
13 |
actually *solve* the problem which is this discussion was started. |
14 |
|
15 |
Rember: we started with the thesis, "grandma wants graphical |
16 |
frontends whereever possible". This is in fact not an technical |
17 |
issue, instead a matter of personal taste, or lets say, an individual |
18 |
system configuration. Grandma wants to click, okay, so she should |
19 |
use graphical applications. She's not interested what sits behind, |
20 |
she just wants to have a buch of applications. And she also doesn't |
21 |
wann have anything to do with emerge and useflags. She just wants |
22 |
to have a choice between a bunch of end-user applications. |
23 |
That's the job of an Grandma-(sub-)distro. |
24 |
|
25 |
Okay, let's say we want to intruduce an meta-useflag for "GUI" |
26 |
(although having additional GUIs in the same package as the |
27 |
backend isn't what I consider clean design). If there's just *one* |
28 |
than it's easy - just an alias. But what's if we have more ? |
29 |
Who makes the decision, which one to take ? Based on what rules ? |
30 |
|
31 |
> Useflags are one of the distinguishing features of gentoo. |
32 |
|
33 |
Yes. For optional features. Additional programs aren't features of |
34 |
some other program, but additional programs. |
35 |
|
36 |
<snip> |
37 |
|
38 |
> It is also against the gentoo philosophy of offering software the |
39 |
> way upstream provides it. |
40 |
|
41 |
Ah, and this philosophy is more important than quality and |
42 |
maintainability ? |
43 |
|
44 |
<snip> |
45 |
|
46 |
> > > > Some |
47 |
> > > > people @mplayerhq are quite aeh, unfortunate, about changes in the |
48 |
> > > > build procedure. Maybe you like to have a look at the discussion |
49 |
> > > > about my patches introducing pkg-config utilization. |
50 |
> |
51 |
> pkg-config is a broken concept. |
52 |
|
53 |
Ah ? |
54 |
|
55 |
I consider it *very* clean. What could be easier than have an |
56 |
consistent database which *knows* what's installed on the system |
57 |
instead of having to run lots of esoteric tests which shall *guess* |
58 |
it somehow ?! |
59 |
|
60 |
If necessary, this database query can be intercepted easily. With |
61 |
the esoteric testing its very complicated or at least work intensive. |
62 |
|
63 |
BTW: have to ever tried to crosscmompile a whole system in a clean |
64 |
sysroot'ed environment ? |
65 |
|
66 |
<snip> |
67 |
|
68 |
> Libraries themselves should state dependency information. |
69 |
|
70 |
Hah, but only *should*, not actually *do*. |
71 |
Okay, ELF so's can contain such information, but that's only a little |
72 |
part of an library. There's much, much more. |
73 |
|
74 |
Well, how would you get certain search pathes (-I, -L, ...) |
75 |
additional includes, dependency info for evrything but elf-so, ie .a ? |
76 |
|
77 |
> Pkg-config is a "solution" that introduces at least as many |
78 |
> problems as it solves. |
79 |
|
80 |
Example ? |
81 |
|
82 |
<snip> |
83 |
|
84 |
> Only libtool (esp. old versions) is worse in it's incomplete use |
85 |
> of the linker and the way it encourages broken library linking. |
86 |
|
87 |
Libtool is isn't just broken, it's totally misconception. |
88 |
But that's another story and has *nothing* to do with pkg-config. |
89 |
|
90 |
|
91 |
cu |
92 |
-- |
93 |
--------------------------------------------------------------------- |
94 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
95 |
--------------------------------------------------------------------- |
96 |
Please visit the OpenSource QM Taskforce: |
97 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
98 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
99 |
http://patches.metux.de/ |
100 |
--------------------------------------------------------------------- |
101 |
-- |
102 |
gentoo-dev@g.o mailing list |