Re: [gentoo-dev] GTK und GTK2 Use Flag

[Brian Harring <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Wed, Mar 30, 2005 at 01:13:12AM +0200, foser wrote:
> On Tue, 2005-03-29 at 16:29 -0600, Brian Harring wrote:
> > If you use the approach I've laid out (yes, not new, I laid it out in 
> > 24439) you wouldn't have to dick around with deprecating a version, 
> > nor essentially mandating what version is default.  You'd leave the 
> > total control over what versions the user wants to deal with in the 
> > hands of the _users_, and what versions the package supports would 
> > be represented properly/clearly in the IUSE.
> 
> I know the proposed system obviously and it's still flawed in that
> really doesn't deal with USE flag versioning in a consistent,
> predictable way.
State how it's flawed please.  If you're going to argue this is a 
repeat of the gtk2/gtk fiasco that's in the tree currently, please 
validate how/why it is.  The approach detailed above, and in aug '04 
*is* the most flexible approach with use flags that addresses user 
needs, and is extensible (gtk3).

> > So far... I've not really heard a good reason aside from "it's in 
> > place, we'll just deprecate gtk v1 instead of clean it up" for why 
> > this cannot be corrected _now_, or really in the past.
> 
> That is all the reason needed here. I'm no biggie on the current
> situation (altough if people actually read the USE flag descriptions it
> wouldn't be half the issue), but interchanging to be deprecated
> behaviour with something just as bad is a regression. I'll post more on
> some changes that I'd like to see implemented for this later.
> 
> And the issue never has been about changing a few occurances in the
> tree.

Well, the issue is what then?  It's an often requested change.  While 
people *should* know wth they're flipping on via looking in use.desc, 
use flags *should* be relatively sane/clear in their implications, at 
least on a general scale.
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]