On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 7/1/07, Michael Homer <[EMAIL PROTECTED]> wrote: > > On 7/2/07, mpb <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > There was talk back in May of adding USE-flag style functionality to > > > Compile: > > > > > > http://www.wotfun.com/pipermail/gobolinux-devel/2007-April/002570.html > > > http://www.wotfun.com/pipermail/gobolinux-devel/2007-May/002580.html > > <snip> > > > > > > You might, for example, want to Compile against Optional-Installed > > > dependencies, but at the same time to Skip Optional-Absent > > > dependencies. > > Everything above this point sounds fine to me. It would be nice to > > have more general flags than just dependencies, I think, but I haven't > > come up with an example of why yet. I just have a niggling feeling > > that enabling "GTK" might do more than just compiling against GTK. > > Maybe more on that later if I can think of it. > > If you think about "enabling GNOME" then I believe it gets easier to > conclude that it's more than just compiling against one or other > library. You'd probably want it to change dependencies and configure > (as in "settings files") things in different ways. That's the case I was looking for. GNOME wouldn't even be a dependency, it would be the individual packages. > > What about cases where one flag affects another? Dependencies could be > > mutually-exclusive, in fairly complex ways, or one could require > > another, or one could require a disjunction of others (to enable > > feature X you need Sun-JRE OR Sun-JDK OR Blackdown-JRE OR ...). > > > > That brings something else to mind: Gentoo has "virtual" packages to > > cover cases where there are multiple implementations of the same > > thing: virtual/ghostscript, virtual/x11, virtual/jre, virtual/emacs, > > and others. Ebuilds are said to "provide virtual/ghostscript". That > > sort of solution would remove a lot of the complexity, but probably > > not all of it, and it might make a bit of a mess of /Programs. > > Although symlinks /Programs/JDK->/Programs/Sun-JDK might not be so > > bad. > > I think the same. Probably something to be added as a next step > afterwards though (in other words, a good idea but not essential to > the core of things). > > > I like the different levels of necessity. I am a little wary of how > > recommended/discouraged is going to be determined, but I doubt it > > would really be a problem. I also like the control there is at > > different levels of detail. > > I am very wary about how this would be determined (thinking about > community/social/flamewar implications, rather than technical issues). > I'd rather avoid this can of worms and stick to something that can be > unequivocally determined, reducing the spectrum to "required", > "optional" and (the eventually phased-out) "unlabeled". Even then, > there is always the issue of app-specific flags and whether they will > be enabled or disabled by default (where being enabled by default > amounts to being "recommended" and disabled by default to being > "discouraged", I understand.) So, yes, to some degree it is an > unavoidable problem (unless you want to shy away and ask the user > everything). But its an unsolvable problem in the global sense, as > it's impossible to make _everyone_ happy with the chosen defaults, but > then that's why they're just "defaults" and not hardcoded behavior. > (All right, I'm just rambling, throwing ideas to the table. I haven't > made up my mind on this issue.) That's the same wariness I have. But there are going to be things that default to on without being mandatory, so it's going to come up no matter what. What goes into the binary packages has much the same issue, and it hasn't been a problem, so it would probably be ok.
However, after some thought I'm not sure how much "recommended" would be used, at least as I saw it. I was thinking of "it is recommended that you enable SSL support for security reasons" as an example. I'm less keen on "it is recommended that you enable GTK+". So it might be an area best avoided. The profiles idea Isaac suggested could help. I think that has many of the same problems, though, and the combining part looks a little confusing. If there are going to be different profiles anyway, as has come up from time to time, I think it'd be a good way to do them. Wearing my Freshen hat for a moment, I'm actually not that fond of anything that requires prompting the user and isn't avoidable. So I would prefer that asking never happen, and that there be some way to determine if there's a conflict and just die right at the beginning. > > > 2) Dependency Flavors would not handle the case of Compiling only a > > > specific Xorg video driver. I believe "USE-flags"/Flavors should be > > > used for cross-recipe configuration, not intra-recipe configuration. > > > I'm not opposed to intra-recipe configuration mechanisms, but I think > > > intra-recipe configuration is a separate (and much simpler) problem, > > > and should be solved separately and without cluttering up the global > > > "USE-flag" namespace. > > It is cross-recipe. The recipe "Xorg" depends on the recipe > > "XF86-Video-I810". > > I think solving intra-recipe and cross-recipe issues with the same > mechanism would be better. Being pragmatic, I don't think cluttering > up the "USE-flag" namespace is that big of a deal. Two things should > help: one is avoiding to fall into the trap of trying to map every > available configure flag; another is to define some namespace rules > such as "if a flag is used in only one program, it must be prefixed by > the program name". I'd like to be careful about doing that, since it ties us down in case something new comes along later. We don't want our flag called "xorg-video-i810" only to find out later that Xine has direct support for the card too (not an artificial example, it really does). So prefixing should only be in the cases that are genuinely specific to one program, semantically. Gentoo, by the way, sidesteps that particular problem by having the setting be VIDEO_CARDS="i810 i915 ..." in make.conf. Internally they're converted to USE flags of the form "video_cards_i810", but that's invisible to the end user. I'm not sure that that's necessary or all that useful though. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
