On Fri, Sep 26, 2008 at 5:05 PM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > 2008/9/26 Lucas C. Villa Real <[EMAIL PROTECTED]>: >> On Thu, Sep 25, 2008 at 8:09 PM, Michael Homer <[EMAIL PROTECTED]> wrote: >>> On Fri, Sep 26, 2008 at 10:01 AM, Lucas C. Villa Real >>> <[EMAIL PROTECTED]> wrote: >>>> On Tue, Sep 23, 2008 at 5:46 AM, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >>>>>> My main concern is that the answer for scenario 1 is "no". I don't >>>>>> mind if the answer for scenario 2 is "yes" or "no", as long as the >>>>>> semantics are clearly defined. (Is the behavior of scenario 2 the >>>>>> point of disagreement between Michael and Jonas?) >>>>> Scenario 1: >>>>> Today: yes. >>>>> With my implementation: no. >>>>> >>>>> Scenario 2: >>>>> Today: probably(!) - if best gui available. >>>>> With my implementation: Same as today >>>>> >>>>> The disagreement is not in scenario 2, but in scenario 1. I want >>>>> "-tcltk" to affect what the generic flags enable. Today generic flags >>>>> are parsed last and if no specific flag in a group is set in an >>>>> earlier stage the generic flag will enable best available. I want that >>>>> setting "-tcltk" in an earlier stage will not enable tcltk, even when >>>>> it is the best available or only (if optional) gui. >>>> That's what I would expect from "USE=-tcltk", too. >>> If you don't want to use the generics, turn them off (or just erase >>> the file, and you can never even turn them on by accident). If you >>> don't want to use a specific one, turn it off. If you don't ever want >>> to use a particular potential component of one of the generics, take >>> it out. If you want to use a particular implementation for a given >>> program, enable the flag for it. This is an unnecessary massive >>> complication of the system that gains absolutely nothing, since >>> everything you could possibly want it for is already available and >>> better expressed by saying what you actually want. Tri-state flags are >>> a shambles. There's no "asking to turn something off", there's just >>> turning it off then and there. Anything else is a mess. > > I still don't understand the issue behind tri-state flags. What's so > evil and ugly about it? I think we went through it earlier and > straighten out most issues with having tri-state flags. They are unimplementable, inherently come into conflicts, don't actually do what anybody expects, and have a terrible interface. -foo should disable the flag, it shouldn't be a promise to do something later on. And there's really no use in adding further complications - and it is a complication, particularly if you consider how it would actually work on the inside - to gain absolutely nothing. Everything is already possible. However, more thoughts at the bottom on what the actual problem is... > Also this is about what a user (at any level) would expect if -tcltk > is set. To me it would say: don't use tcl/tk, not even if found as an > entry in a generic flag "Set -tcltk" is the problematic mindset here, and that's the part I don't understand. You asked to have it on already; if you don't want it, stop asking for it. Each entry in the file is a command to do something, not a condition on possible states of the world. > The issue (from my point ot view) brought up with this discussion is > that even if you have -tcltk set generic flags may still enable it, > which means that ChrootCompile will include tcl/tk in the chroot. If and only if you asked for a gui and tk was the most preferred available. If you ask for a gui you should get it if at all possible. Having disabled one of its components in general shouldn't affect that. I thought about having that behaviour just for program-specific flags, but then it's just the same work as enabling the component you actually want to use so there didn't really seem to be a point.
It seems that really the issue is that people may not know where their enabled flags all came from. Perhaps the tools could be more verbose about that - at the moment it's a bit of a black box. If it displayed the enabled flags and the information from the current UseFlags --debug, tidied up for public consumption, through the standard logging mechanism at the start (and maybe end) of each Compile that would be clearer. If you know where it came from you're better able to disable it or set things up to be the way you want, without having weird behaviour from a distance in the name of simplicity of configuration. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
