Re: [gentoo-dev] Proposal for advanced useflag-syntax

[Enrico Weigelt <weigelt@metux.de>]

* Paul de Vrieze <pauldv@gentoo.org> 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