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: >>> Clarification: >>> Generic flags are defined in Settings/GenericFlags.conf. >>> Setting flags you do in Data/DistUseFlags.conf, Settings/UseFlags.conf >>> and USE environmental variable. >>> >>> Flags are parsed and enabled in this order: >>> DistUseFlags.conf, Settings/UseFlags.conf, USE environmental variable, >>> flags selected by generic flags >> As a simple suggestion, I'd rather name GenericFlags.conf >> "UseFlagsDatabase.conf", or something similar -- because that's where >> we set our "database". > No it isn't. At least, I don't think so... "database"?
That's why it was surrounded by quotes. That's where we the assignments are done, and we later on select in UseFlags.conf which of those we want to enable/disable. Hence, I think it deserves a better, more descriptive/less confusing name. UseFlagsDatabase.conf was just a wild name -- maybe UseFlagsList.conf would be a better one? >>>> 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. >> Also, it's important that's the script loads ~/.Settings/UseFlags.conf >> if such file exists, allowing users without privilege to edit >> /S/S/UseFlags.conf to override its contents. That should be extended >> to general conf files, too, as it came to my surprise now that >> currently we only parse ~/.Settings if no global file has been found. > It should do that. Well, as long as we have a way to overwrite the system flags throughout ~/.Settings, I'm ok with that. That could even deprecate USE=, but then that's another story. Lucas _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
