On 7/2/07, Michael Homer <[EMAIL PROTECTED]> wrote: > On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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.
Agreed. It's an unavoidable problem (as choices have to be made at the very least for binary packages) and I agree that Isaac's idea of taking the decisions of what's recommended and what's not out of the recipes and into profiles is a good one. (And I also found the profiles part confusing :) ) > 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. What I'd love to have is a list of "stable versions" that Freshen could download and use, listing versions for all recipes so that "for the programs you have, if you have _these_ versions-revisions installed, they'll all work". Maintaining that list, though, is the trick for having a stable distro. > > > > 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. I was thinking along the lines of expanding the namespace in an as-needed basis. A flag could start as "xorg-video-i810" and then when we realize we can use it on other package we'd add a "video-i810" flag and make the old flag an alias to the new one. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
