Gentoo Archives: gentoo-dev

From: Enrico Weigelt <weigelt@×××××.de>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Proposal for advanced useflag-syntax
Date: Mon, 07 Aug 2006 14:24:22
Message-Id: 20060807141821.GI25236@nibiru.local
In Reply to: Re: [gentoo-dev] Proposal for advanced useflag-syntax by Paul de Vrieze
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

Replies

Subject Author
Re: [gentoo-dev] Proposal for advanced useflag-syntax Alec Warner <antarus@g.o>
[gentoo-dev] Re: Proposal for advanced useflag-syntax Duncan <1i5t5.duncan@×××.net>
Re: [gentoo-dev] Proposal for advanced useflag-syntax Paul de Vrieze <pauldv@g.o>