* Paul de Vrieze <[EMAIL PROTECTED]> schrieb: <snip>
> > Well, I don't consider reducing complexity "frivolous" ;-o > > Which reduction for which complexity? Do you want to bring everyone's > systems to a grinding halt, just because you can't understand the > "complexity" of useflags. I just want to keep things simple. We're talking about introducing new (additional) logic. This has to be maintained. And it doesn't actually *solve* the problem which is this discussion was started. Rember: we started with the thesis, "grandma wants graphical frontends whereever possible". This is in fact not an technical issue, instead a matter of personal taste, or lets say, an individual system configuration. Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. Okay, let's say we want to intruduce an meta-useflag for "GUI" (although having additional GUIs in the same package as the backend isn't what I consider clean design). If there's just *one* than it's easy - just an alias. But what's if we have more ? Who makes the decision, which one to take ? Based on what rules ? > Useflags are one of the distinguishing features of gentoo. Yes. For optional features. Additional programs aren't features of some other program, but additional programs. <snip> > It is also against the gentoo philosophy of offering software the > way upstream provides it. Ah, and this philosophy is more important than quality and maintainability ? <snip> > > > > Some > > > > people @mplayerhq are quite aeh, unfortunate, about changes in the > > > > build procedure. Maybe you like to have a look at the discussion > > > > about my patches introducing pkg-config utilization. > > pkg-config is a broken concept. Ah ? I consider it *very* clean. What could be easier than have an consistent database which *knows* what's installed on the system instead of having to run lots of esoteric tests which shall *guess* it somehow ?! If necessary, this database query can be intercepted easily. With the esoteric testing its very complicated or at least work intensive. BTW: have to ever tried to crosscmompile a whole system in a clean sysroot'ed environment ? <snip> > Libraries themselves should state dependency information. Hah, but only *should*, not actually *do*. Okay, ELF so's can contain such information, but that's only a little part of an library. There's much, much more. Well, how would you get certain search pathes (-I, -L, ...) additional includes, dependency info for evrything but elf-so, ie .a ? > Pkg-config is a "solution" that introduces at least as many > problems as it solves. Example ? <snip> > Only libtool (esp. old versions) is worse in it's incomplete use > of the linker and the way it encourages broken library linking. Libtool is isn't just broken, it's totally misconception. But that's another story and has *nothing* to do with pkg-config. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- gentoo-dev@gentoo.org mailing list
