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. 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 (still mandatory dependencies shouldn't be flagged). Sure, you can edit GenericFlags.conf and take out "tcltk", but still, what would the user expect from -tcltk? Why should we force users to learn GenericFlags.conf if we can add flexibility to the system (without removing functionallity). >>> 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. > There is two things that needs to be explained, it seems: 1) Flags can always be overridden in a later level (and not parsing ~/Settings for complementary settings is a long standing bug). 2) Currently use flags cannot be turned *off*. Setting -tcltk doesn't pass "--disable-tcl" to ./configure. It just tries to make sure that the Dependancy isn't asked for and that "--enable-tcl" isn't passed to ./configure. I.e. -tcltk doesn't turn it off. If tcl/tk is found by ./configure it will still use that. This is by design, as we came to the conclusion that ChrootCompile should be default and that by only using selected dependencies (selected by recipe author and use flags) in the chroot, it would be easier to just leave it to ./configure. Not having tcl/tk available in the chroot would be equivalent to explicitly passing "--disable-tcl" to ./configure, but much simpler. 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. -- /Jonas _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
