| 1 |
On Monday 07 August 2006 16:18, Enrico Weigelt wrote: |
| 2 |
> I just want to keep things simple. We're talking about introducing |
| 3 |
> new (additional) logic. This has to be maintained. And it doesn't |
| 4 |
> actually *solve* the problem which is this discussion was started. |
| 5 |
|
| 6 |
Removing the stuff from the ebuild and maintaining two ebuilds that must be |
| 7 |
synchronized with eachother is complex. |
| 8 |
> |
| 9 |
> Rember: we started with the thesis, "grandma wants graphical |
| 10 |
> frontends whereever possible". This is in fact not an technical |
| 11 |
> issue, instead a matter of personal taste, or lets say, an individual |
| 12 |
> system configuration. Grandma wants to click, okay, so she should |
| 13 |
> use graphical applications. She's not interested what sits behind, |
| 14 |
> she just wants to have a buch of applications. And she also doesn't |
| 15 |
> wann have anything to do with emerge and useflags. She just wants |
| 16 |
> to have a choice between a bunch of end-user applications. |
| 17 |
> That's the job of an Grandma-(sub-)distro. |
| 18 |
|
| 19 |
gentoo is not a grandma distro and does not try to be so. |
| 20 |
|
| 21 |
> |
| 22 |
> Okay, let's say we want to intruduce an meta-useflag for "GUI" |
| 23 |
> (although having additional GUIs in the same package as the |
| 24 |
> backend isn't what I consider clean design). If there's just *one* |
| 25 |
> than it's easy - just an alias. But what's if we have more ? |
| 26 |
> Who makes the decision, which one to take ? Based on what rules ? |
| 27 |
|
| 28 |
The council makes the decisions. |
| 29 |
|
| 30 |
> Yes. For optional features. Additional programs aren't features of |
| 31 |
> some other program, but additional programs. |
| 32 |
|
| 33 |
You should read up on your history. Useflags are as well for additional |
| 34 |
programs as for features. This is especially true when things should be kept |
| 35 |
together as they are tightly coupled. |
| 36 |
|
| 37 |
> Ah, and this philosophy is more important than quality and |
| 38 |
> maintainability ? |
| 39 |
|
| 40 |
You fail to see that what we do has quality and is certainly maintainable. |
| 41 |
|
| 42 |
> > pkg-config is a broken concept. |
| 43 |
> |
| 44 |
> Ah ? |
| 45 |
> |
| 46 |
> I consider it *very* clean. What could be easier than have an |
| 47 |
> consistent database which *knows* what's installed on the system |
| 48 |
> instead of having to run lots of esoteric tests which shall *guess* |
| 49 |
> it somehow ?! |
| 50 |
|
| 51 |
The tests don't actually guess. The main problem though is that pkg-config |
| 52 |
encourages wrong linking. Linking should happen properly such that libraries |
| 53 |
link in their own dependencies, so that library users don't have to. |
| 54 |
|
| 55 |
> If necessary, this database query can be intercepted easily. With |
| 56 |
> the esoteric testing its very complicated or at least work intensive. |
| 57 |
|
| 58 |
There is nothing esoteric about checking for the existence of libfoo. |
| 59 |
|
| 60 |
> Well, how would you get certain search pathes (-I, -L, ...) |
| 61 |
> additional includes, dependency info for evrything but elf-so, ie .a ? |
| 62 |
|
| 63 |
The thing is you don't should not link the dependent libs of a dependency. |
| 64 |
That way you don't need to recompile if (say gtk was compiled with a new |
| 65 |
libpng version) |
| 66 |
|
| 67 |
Paul |
| 68 |
|
| 69 |
-- |
| 70 |
Paul de Vrieze |
| 71 |
Gentoo Developer |
| 72 |
Mail: pauldv@g.o |
| 73 |
Homepage: http://www.devrieze.net |
Archives